Support Forums

Function not loading due to Runtime.MalformedHandlerName error message

My Go function is not working.

The error message is:

{"errorType":"Runtime.MalformedHandlerName","errorMessage":"Bad handler","trace":["Runtime.MalformedHandlerName: Bad handler","    at _splitHandlerString (/var/runtime/UserFunction.js:43:11)","    at Object.module.exports.load (/var/runtime/UserFunction.js:138:31)","    at Object.<anonymous> (/var/runtime/index.js:43:30)","    at Module._compile (internal/modules/cjs/loader.js:999:30)","    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)","    at Module.load (internal/modules/cjs/loader.js:863:32)","    at Function.Module._load (internal/modules/cjs/loader.js:708:14)","    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)","    at internal/main/run_main_module.js:17:47"]}

The site is https://stage--viz-redistricting-2020.netlify.app/

The code is GitHub - spotlightpa/viz-redistricting-2020 at 653f9a63ebd4899362c4d547a0fd3866ebc07177

Note that this was working before, and so far the main branch has not stopped work: https://viz-redistricting-2020.netlify.app

I believe this error must be caused by a change in Netlify’s deployment process.

If you curl an old preview deploy link, it correctly returns my handler’s 404 message:

curl https://61b3c6d715d7a2000895589d--viz-redistricting-2020.netlify.app/.netlify/functions/geolocator

I redeployed the exact same commit, but now the preview link incorrectly returns the malformed handler message:

curl https://61b7af333115cc11a8647c1f--viz-redistricting-2020.netlify.app/.netlify/functions/geolocator

This is definitely Netlify’s bug. I added an empty commit to one of my other repos, and now it has the same error message on its PR deploy.

This is a very high priority bug for me, because I cannot deploy any of my repos that use Go functions until it is resolved.

Hey Carl,

Can you give us a code example that causes this? You’re the only person who’s reported it so far as far as I can tell, but we also have only a handful of people using Go functions, so I’m not super surprised by this.

It happens with two different repos. In both, I have a build script that runs GOBIN=$THIS_DIR/functions go install ./cmd/... and then the netlify.toml looks like

from = "/api/*"
to = "/.netlify/functions/nameofbinary/:splat"
status = 200

I don’t know how to be more specific. It wasn’t happening last Friday, as you can tell by looking at the old permalink URLs.

I tried out another one of my repos, and yup, deploying killed it.

Here is the site: https://go-function-demo.netlify.app/api/feed

Here is the repo: GitHub - carlmjohnson/netlify-go-function-demo: https://blog.carlmjohnson.net/post/2020/2020-03-01-how-to-host-golang-on-netlify-for-free/

Here is the blog post I wrote about the repo when it was created: How to Use Netlify to Deploy a Free Go Web Application Β· The Ethically-Trained Programmer

Here is the deploy log for that demo repo: Netlify App

It says this, which my other repos do not (or at least not in the logs that I have read so far):

9:47:34 PM: ────────────────────────────────────────────────────────────────
9:47:34 PM:   3. Deploy site                                                
9:47:34 PM: ────────────────────────────────────────────────────────────────
9:47:34 PM: ​
9:47:34 PM: Starting to deploy site from 'public'
9:47:35 PM: Function "manifest.json": Go binary does not have executable permissions
9:47:35 PM: Function "manifest.json": Function is not valid for deployment. Please check that it matches the format for the runtime.
9:47:35 PM: Creating deploy tree 
9:47:35 PM: Creating deploy upload records
9:47:35 PM: 0 new files to upload
9:47:35 PM: 1 new functions to upload
9:47:42 PM: Site deploy was successfully initiated

This may be because this particular repo is very stale. I will try upgrading it and see if it still complains about the binary not being an excutable. Seems like a red herring.


Ah, if only I could time travel to back to the simpler days of commit 2b35eba…

Okay, I upgrade Go and added an explicit chmod +x step to build.sh, but the deploy log still says the thing about the executable not having permission:


Is it possible something changed on Netlify’s side that would screw up binary permissions? Like are you copying the binaries from A to B somewhere or something?

The executable thing still smells weird.

In the repo I was working on today, this deploy from 2:22pm EST works:


(You can test the repos by going to the page and entering the name of a city in Pennsylvania.)

This deploy from 2:34pm does not:


In theory, the only difference between them is that I added some tags to a static file header: Preload fonts Β· spotlightpa/viz-redistricting-2020@efff018 Β· GitHub

The Netlify docs here say you make a Go function by just putting unbuilt .go files in a functions sub-folder. I have always built executables with build scripts. Did this change at some point? It does seem simpler to just have .go files, like .js files, but maybe it changed at some point and I’ve been using a legacy code path that suddenly broke?

I switched the demo site to just use cmd/ as its functions folder and not run the build script, but that did not fix it.


Hi, @carlmjohnson. I’ve escalated this to our developers to have them take a look at this site’s builds and functions to get their input on how to get these functions working.

I made an attempt at debugging this and one thing I noticed is that the functions in question do not appear to use the handler function required as stated in the documentation here:


When I examine the function code, I see no such handler function defined. For example here:


I see this:

package main

import (


func main() {

Is the handler function defined in some other file?

Again, I’ll let you know what our developers say but the answer to the questions above might come up in that investigation. So, I wanted to ask as soon as possible so we have the answers if our developers ask about it.

It does call lambda.Start, but it’s hidden behind some library calls so that you can also run the handler on your dev machine like a normal HTTP server. It’s explained in more detail in the blog post.

Should be working again, Carl – our team shipped a fix. I am not sure if you’ll need a redeploy of the functions or not, but if they aren’t working, please add an env var in the UI and deploy your site again normally; that should certainly get things back up to snuff.


Thanks. I will redeploy and let you know if I see any remaining bugs.

1 Like

Looks good. I’m not seeing any problems in my repos.

Thank you for reporting this, @carlmjohnson. It is your report which initially brought attention to this issue and helped us to get this fix out quickly. Thanks again for sharing the reproduction and for letting us know about the issue.

1 Like