Failed to upload file: &{Name:submission-created during build

I’m trying to use netlify and its lambda function feature to run a node function. Based on https://css-tricks.com/using-netlify-forms-and-netlify-functions-to-build-an-email-sign-up-widget/.

I’m having trouble getting node modules to work (see https://stackoverflow.com/questions/65134613/importmoduleerror-errormessageerror-cannot-find-module-while-using-netlify)

Currently my netlify.toml has only the following:

[build]
  functions = "./functions"
  command = "npm run-script build"

and my package.json:

{
  "name": "test2",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "npm install && npm build"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/kc1/test2.git"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/kc1/test2/issues"
  },
  "homepage": "https://github.com/kc1/test2#readme",
  "dependencies": {
    "dotenv": "^8.2.0",
    "node-fetch": "^2.6.1"
  }
}

You can see the deploy log here: https://app.netlify.com/sites/inspiring-ardinghelli-4a4da5/deploys/5fd180d4db83b400073f8694. What am I doing wrong?

The github repo now at https://github.com/kc1/static1/

also now deploying to https://app.netlify.com/sites/hopeful-ritchie-b062b1/overview with same issue

the build worked initially but now https://app.netlify.com/sites/hopeful-ritchie-b062b1/deploys/5fdc096b65484600082949d1

Hey @kc1,
Let’s try to narrow the scope of the issue a bit. Can you replace your whole function with just:

exports.handler = async function(event, context) {
   console.log(JSON.parse(event.body))
   return {
     statusCode: 200,
     body: event.body
   };
};

And then we can see if the issue is with the function itself or with something else?

Thanks for looking at this Jen. I’ve done that. Please see the repo above. The same error appears to be occuring: https://app.netlify.com/sites/inspiring-ardinghelli-4a4da5/deploys/5fd980f62221930008c3f8dd and
https://app.netlify.com/sites/hopeful-ritchie-b062b1/deploys/5fdd1ea0d8192300087d845d

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:

  1. you have a “base” command when that doesn’t seem to be necessary based on your repo structure.
  2. your build command in the site dashboard here: https://app.netlify.com/sites/inspiring-ardinghelli-4a4da5/settings/deploys#build-settings 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:
[build]
  command = "#"
  functions = "functions"

Let us know how that goes!

Thanks again! After making the changes to the toml file, I see the same error: https://app.netlify.com/sites/inspiring-ardinghelli-4a4da5/deploys/5fdd5008ee7021000718e6d5 and https://app.netlify.com/sites/hopeful-ritchie-b062b1/deploys/5fdd50089824db0007cb9544 .

Hi Jen, are you still there?

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?

Hi Jen, thank you and that appears to have done it . the modified site is live! What now? Do I need to embed my env variables in code?

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:

VAR1=val1,VAR2=val2...

(Lambdas only accept 4kb worth of environment variables, minus some encoding overhead: https://aws.amazon.com/premiumsupport/knowledge-center/lambda-environment-variable-size/). It’s a limitation in their platform which we are all burdened with…

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.