Thanks! That’s great to know- so the issue is not with the function.
I see a few things that could be causing problems in your netlify.toml:
you have a “base” command when that doesn’t seem to be necessary based on your repo structure.
your build command in the site dashboard here: Netlify App is npm run-script build and then the “build” command in your package.json is npm install && npm build. But I don’t actually see that you’re using a framework to build your site (like Gatsby or Nuxt)- so you might be able to get away with just "#" as your build command. That wouldn’t actually build your site, since there’s nothing to build, but it would install the dependencies you need for the function. So to recap, could you try with a netlify.toml like this:
Hi @kc1,
Our support team takes turns responding to tickets here and in our helpdesk. I’m sorry that no one else got to this question, but I am indeed still here!
The one last idea I have for you to try is to remove your environment variables, hopefully only temporarily. I’ve seen this error before when the environment variables are too big to upload. Want to give that a try and see if it helps?
Hey @kc1,
Hmmm… I’m not sure, since environment variables that functions need to access must be entered in the UI- they can’t be added via netlify.toml. Is there any way to make your environment variables smaller or break them up in some way?
These are credentials from an outside API so I doubt it. I hate to embed that sort of info in code. I think best practices are to use .env files locally and put them in the ui in production. I’m suprised this has not come up before . Any other ideas or anyone else you can ask?
It’s a complicated problem to solve; I think that you’d have the same limit in your own AWS account using lambdas as well - around the total length of environment variables you can use, when concatenated like this into a single text string:
So, your best practice is going to be to pass more than 4k worth of needed details in “some non-environment variable way that is compatible with the rest of your needs”. That would include of course following your local security best practices, etc.
One pattern that isn’t “just cram all of the keys into the repository” is a secure key value store that can either be accessed from the function to do the lookup for the details it’ll need (less efficient but easier to iterate on - you can rotate keys without a redeploy, or have “test” keys that always return a known value based on being called a special way, etc) or is used only at build time (more flexible and less error prone overall since the build environment can more easily make remote calls and handle errors, since it doesn’t have to all complete very quickly like a function run does). This path only requires a single call to this “service” for each build, so it can be something kind of indirect like: “use a password stored in an environment variable in netlify’s UI (safely, out of the repo), to access the longer token stored on a password-protected webpage” (which also keeps the token out of the repo). If you were to use the during-build workflow, you would write the value to a file your function includes where you could read it at runtime.
I know, those are all workarounds, but hopefully one of them can inspire a workflow that feels like you could live with it.