Functions failing in new deploys

[carlana]

I am getting this error message from new deploys:

{
    "errorType": "Runtime.UserCodeSyntaxError",
    "errorMessage": "SyntaxError: Invalid or unexpected token",
    "trace": [
        "Runtime.UserCodeSyntaxError: SyntaxError: Invalid or unexpected token",
        "    at _loadUserApp (/var/runtime/UserFunction.js:98:13)",
        "    at Object.module.exports.load (/var/runtime/UserFunction.js:140:17)",
        "    at Object.<anonymous> (/var/runtime/index.js:43:30)",
        "    at Module._compile (internal/modules/cjs/loader.js:1158:30)",
        "    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)",
        "    at Module.load (internal/modules/cjs/loader.js:1002:32)",
        "    at Function.Module._load (internal/modules/cjs/loader.js:901:14)",
        "    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)",
        "    at internal/main/run_main_module.js:18:47"
    ]
}

My functions use Go, not JS, so I’m not sure what’s going on.

[carlana]

I had been in the Build plugins beta. I opted out and did a fresh PR, and that seems to be working.

Maybe Build plugins aren’t compatible with Go functions?

[ehmicky]

Hi @carlana!

The Netlify Build beta should be backward compatible, including Go Functions.

This seems to be a bug with Go Functions support in the Netlify Build beta. I can reproduce your problem. I have created a GitHub issue here and am working on a fix.

Thanks for reporting this problem!

[ehmicky]

We have just fixed this problem.

Could you confirm your Go Functions are now working when the Build plugins beta is enabled? Thanks!

[devops_team]

I’ve run into almost the same error message as carlmjohnson right down to the line numbers when attempting to deploy a new sveltekit ssr app. (Carl was deploying a new Go App).

{
“errorType”:“Runtime.UserCodeSyntaxError”,“errorMessage”:“SyntaxError: Unexpected token ‘.’”,“trace”:[“Runtime.UserCodeSyntaxError: SyntaxError: Unexpected token ‘.’”," at _loadUserApp (/var/runtime/UserFunction.js:98:13)“,” at Object.module.exports.load (/var/runtime/UserFunction.js:140:17)“,” at Object. (/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 differences begin at the module loader (Carl’s line # 1158:30) and ours is (999:30) hopefully this helps narrow down root cause.

Any assistance would be appreciated.

Thanks

[hrishikesh]

Are you using optional chaining by any chance? If yes, that might need Node 14 runtime: Build functions | Netlify Docs

[devops_team]

Thanks for the reply,

In response, we set the environment key key to AWS_LAMBDA_JS_RUN & the value to 14.x, but still have the issue.

NOw that I look at your response closer, maybe it’s as simple as a spelling issue. I’m sure we followed the docs, but the current docs called the key AWS_LAMBDA_JS_RUN and you have the key as AWS_LAMBDA_JS_RUNTIME

I will change it and attempt the deploy again.

I’ll let you know what happens.

And, no matter what, Thanks for the quick reply.

I really appreciate your help!

[devops_team]

It looks like we’re closer.

1. The aws nodejs reports it is already using 16.x, it did not downgrade to 14.x, but my sense is that’s probably OK, unless the deltas between 14 & 16included an applicable breaking change. If this is the problem, then I have a problem because I’m not sure, yet, how to force nodejs in netlify to14.x except by using the environment variable. (If this is an issue, can you let me know?)

2. There’s also a second, different. error now, which I think is probably the current problme and looks like a simple fix because our function was named differently than what sveltekit’s ssr seems to be expecting. (There is not a lot of detail on this in the docs, because the sveltekit-netlify adapter is still in flux.)

Thank you! I do really appreciate your help. It’s already made a difference

I’ll let you know what happens.

[hrishikesh]

@devops_team

The aws nodejs reports it is already using 16.x,

AWS doesn’t support Node 16 yet:

Lambda runtimes - AWS Lambda

[devops_team]

Hrihikesh… Thank you!

How do I downgrade it to 14.x with environment variables?

Here’s what we see in the log:
…
8:27:15 AM: Installing dependencies
8:27:15 AM: Python version set to 2.7
8:27:16 AM: v16.13.0 is already installed.
8:27:16 AM: Now using node v16.13.0 (npm v8.1.0)
8:27:16 AM: Started restoring cached build plugins
8:27:16 AM: Finished restoring cached build plugins
…

THANK YOU!

[hrishikesh]

Just like you tried above. By default AWS is using Node 12, so you need to use Node 14 by adding the variable AWS_LAMBDA_JS_RUNTIME and value nodejs14.x

[devops_team]

Thank you.

I added a bit of the logs into my previous post. Look at 8:27:16 AM

I did clear the cache before deploying…

We did NOT have nodejs14.x we had node14.x … fixed and will retry.

THANK YOU!

[devops_team]

That did the trick!

THANK YOU Hrishikesh

Just a FYI, the logs, still report the same node version this time.

8:50:02 AM: Python version set to 2.7
8:50:03 AM: v16.13.0 is already installed.
8:50:03 AM: Now using node v16.13.0 (npm v8.1.0)

I’ll see if I can find the docs we followed and let you know if there were actually any inconsistencies.
If they’re incorrect, and I believe they are, it’ll help others to get them corrected.

Of course, we may have made a mistake as well.

THANK YOU AGAIN!

[hrishikesh]

@devops_team

8:50:03 AM: v16.13.0 is already installed.

That’s the Node version of site builds which is different from AWS runtime.

[devops_team]

Hrishikesh:

THANK YOU AGAIN.

The issue in the docs is an image, you can locate it in the sveltekit area

SvelteKit on Netlify

It shows the incorrect value, it probably was hidden due to the field width, but in any case, it would save you guys some work if they updated the image to reflect “current” reality.

I hope this help you back!

Hrishikesh: It’s comforting to work with professionals like yourself.

You just won Netlify a lot of points. My bet is that a lot of others have made the same mistake. Everyone seems to attribute it to the flux of the adapter, but maybe this is why a lot of people report ssr isn’t working yet.

THANK YOU!

[hrishikesh]

Oh that makes sense. Yeah, the value is getting trimmed because of width. I’ll pass this to the docs team to see if they have a better idea to handle this. Thank you for that.

[hillary]

Hey there, @devops_team

Just wanted to thank you again for sharing this feedback with us. Our Documentation team has updated the image to show the correct value. We appreciate you taking the time to highlight this to us!

Happy building