Unable to execute a simple Go custom handler about functions-custom-handlers HOT 14 CLOSED

One thing I think I can see is that your function is at /convert and your go server api method is at / . Try with a /convert path in your go code too and it should work...

from functions-custom-handlers.

@damoodamoo Even after adding the /convert path, I'm still getting the same error.

from functions-custom-handlers.

Couple of things to check I guess...

• can you hit the go api directly at :port/convert ?
• does this work when running locally?

Can you repaste your updated go code please?

from functions-custom-handlers.

can you hit the go api directly at :port/convert ?

I'm not sure which port to use in this case.

does this work when running locally?

Yup! Running the app with func host start works just fine locally.

Can you repaste your updated go code please?

The code has been updated.

from functions-custom-handlers.

The port is randomly generated but you should be able to set the env var then just run server.exe / or run in debug with vscode or something...

from functions-custom-handlers.

Oh, yeah, there's nothing wrong with the Go binary from my point of view. I think there's something wrong with either the way I setup the function app, the way it's configured, or the way it's deployed.

PS C:\Users\Dylan\Desktop\go-azure-function> $env:FUNCTIONS_HTTPWORKER_PORT = "5000"
PS C:\Users\Dylan\Desktop\go-azure-function> .\server.exe
FUNCTIONS_HTTPWORKER_PORT: 5000
2020/05/14 00:37:24 Go server Listening...on httpInvokerPort: 5000

from functions-custom-handlers.

If this works locally and you can see the go response when hitting localhost:7071/convert then it might be worth checking if you can see the binary has been deployed as well, using kudu

from functions-custom-handlers.

Yup, server.exe is in D:\home\site\wwwroot according to Kudu.

PS D:\home\site\wwwroot> dir
dir


    Directory: D:\home\site\wwwroot


Mode                LastWriteTime         Length Name                          
----                -------------         ------ ----                          
d-----        5/14/2020   3:16 AM                convert                       
------        5/14/2020   3:30 AM            230 host.json                     
------        5/14/2020   6:35 AM        7174656 server.exe                    
------        5/14/2020   6:34 AM            539 server.go

from functions-custom-handlers.

Hmmm that stumps me a bit I’m afraid - I haven’t tried go on a windows host, might be worth trying to build and run on a Linux host in an app service plan?

from functions-custom-handlers.

After trying for quite some time, I'm unable to do even that. Here's the commands I'm using. The final command says that the deployment was successful, but no functions were created.

az group create --name EpubToKpx-appservice-rg --location westus
az storage account create --name epubtokpxstorageapp --location westus --resource-group EpubToKpx-appservice-rg --sku Standard_LRS
az functionapp plan create --name epubtokpx-plan --resource-group EpubToKpx-appservice-rg --location westus --sku B1 --is-linux
az functionapp create --resource-group EpubToKpx-appservice-rg --os-type linux --plan epubtokpx-plan --functions-version 3 --name epubtokpx-app-service --storage-account epubtokpxstorageapp --runtime node
$env:GOOS = "linux"
go build -o server server.go
func azure functionapp publish epubtokpx-app-service --force

Even if this were to work on Linux, the particular workload I'm trying to run requires Windows, so I'd love to figure out a solution to getting that working.

from functions-custom-handlers.

I did find Azure/azure-functions-core-tools#1972 which indicates that I might need to provide some additional flags when deploying, but even with those I still get the same 502 error when accessing my function.

@anthonychu any pointers on where I might be going wrong here? I'm super excited about custom handlers, but man this first experience is pretty rough :(

from functions-custom-handlers.

Alrighty, I've figured this out, and boy was it a bummer to see it wasn't some weird issue with how I was creating the function or something like that.

Nope, it was because the binary was built with Go v1.13.6 and apparently older versions of Go don't like being run inside Windows Docker containers. After upgrading to the latest version of Go and redeploying, everything seems to be working fine.

I discovered that in Kudu I'm able to download a diagnostic dump, which contains the log files for my application. It was there that I saw the Go binary was panicking, and was able to track down the issue.

With WSL2 now supporting Windows 10 Home, I think it'd be really, really awesome if the func CLI could support executing custom handlers inside Docker containers. Had that been an option, I would have been able to track down this issue on my own.

@damoodamoo Thank you so much for the help! I really appreciate you taking the time to assist.

from functions-custom-handlers.

Thanks @damoodamoo for helping. Glad you managed to figure this out, @dstaley. We have an issue to track how to make it easier to diagnose startup errors: Azure/azure-functions-host#6019

Did you get it working by updating to 1.14.2+?

Do you want to run custom handlers in a container on your local machine or do you want it in Azure too?

On your local machine, it should be possible to use a docker command as the httpWorker startup command if you want to run your app in a container (might need this before you can set the port).

Running containers that way is not possible in Azure, however. You'd have to run the runtime and the handler in a container on the premium plan.

from functions-custom-handlers.

Did you get it working by updating to 1.14.2+?

I did! Worked wonderfully. I still don't really understand why the logs didn't appear inside the Monitoring interface in the portal though. Maybe something to look into? In the Kudu Diagnostic dump, the relevant logs were in LogFiles\Application\Functions\Host. It seems like these logs aren't what appear in the Monitoring section of the Portal.

Do you want to run custom handlers in a container on your local machine or do you want it in Azure too?

To start, I'd love it if func host start had an option to execute the function inside of a Docker container that matched the Azure environment as close as possible. It was really confusing for something to work without issue locally and then not work when deployed, especially when it was something as simple as a single Go binary. Since this particular issue arose from being run inside a Docker container, having that issue reproduce locally would have been incredibly helpful.

On your local machine, it should be possible to use a docker command as the httpWorker startup command if you want to run your app in a container (might need this before you can set the port).

It's nice to know this is possible, but I think it'd be really beneficial for there to be at least some indication that what you get with func host start isn't what you're going to get when your handler is executed inside Azure Functions. Even if it's something as simple as a message like the following:

> func host start
It looks like your system has Docker installed. Use `func host start --docker`
to run your function inside a [Windows Server Core | Linux] container to more
closely match the Azure Functions hosting environment.
[ ...output... ]

from functions-custom-handlers.