At seemingly random times Pipedream just throws this Error:
Deploy Error
Workflow failed to build: [some random id]
Can someone explain any possible causes for this?
Hi @roger1
First off, welcome to the community. Happy to have you.
Next time you see that error, could you copy that exact error message and share it with us?
That error ID is useful for us to look into our logs to help troubleshoot what the cause of the issue is so we can help address the problem.
Hey! Thanks for responding so quickly!
Here´s our last error message:
@roger1 thanks so much. Sorry have one more favor to ask, can you copy the text itself - I want to make sure I have each character copied exactly. Otherwise my search in our logs would be incorrect.
Deploy Error
Workflow failed to build: 322fe921-b305-4932-9c88-2023ed808991
further info: when we deploy a new version, even with minor changes like fixed string change, it then works for some iterations, until it hits the error again. no pattern discernible so far that we can relate to our coding logic.
@roger1 thanks for the additional context, very helpful.
We just cleared your execution environments, which power your workflow editor. Hopefully that reset will fix the problem. But if you see any other odd behavior please let me know.
Thank you @pierce
After redeploy, we unfortunately see the same error re-occurring.
Do you recommend any change in memory settings?
Sorry to hear that.
To let us troubleshoot further, do you mind sharing the workflow with support?
You can find the setting under the workflow here:
Also shared our workflow with you, you should be able to access now
Thanks a lot for your support
@roger1 , thanks - that last error message is one that’s familiar.
That package you’re attempting to import is an ESM module, which means you should use the import syntax:
import package from 'package';
That error above means that you’re trying to import it the CommonJS way:
const package = require('package');
However, the package is not distributed that way and the step is erroring out from that particular problem.
Here’s more information on the problem in our docs: Code
ok, thanks for the support. it is still strange because our code didn’t and doesn’t include any require statements and we are already using import; and until this week there were never any problems, the node-fetch parts are unchanged (the commented part is very old from the earliest versions).
From the error log in the error workflow I cannot see from which part of our code this error would be thrown. Any further ideas would be highly appreciated.
Hi again @pierce, was node.js upgraded to a new version recently in the pipedream environment or did you have any known issues with the node-fetch package before? We are not using require statements and still facing the error
Resolution update: were able to solve it with following change
so it seems plain import doesn’t work and we need to always use dynamic import instead
@roger1 glad you were able to find the issue!
So unfortunately, we don’t have the ability to lock to a specific version of any npm package yet.
This means that node-fetch recently updated their package to ship an ESM module version instead of a CommonJS version.
The export / import format is a little different as you see when you’re trying to consume an ESM built package vs a CommonJS one.
For more information - please read the update on the node-fetch package: node-fetch - npm
UPDATE If you prefer the old import way, you can do this instead to continue to use v2 of the library:
const fetch = require('node-fetch@2');
Hi @pierce
even though everything is correctly declared ( const { default: fetch } = await import(‘node-fetch’); ) in all our steps, we are still facing problems with the error Must use import to load ES Module: /opt/ee/node_modules/node-fetch/src/index.js require() of ES modules is not supported.
We are since today also receiving timeout errors that match to the fail to load ES Module errors.
are there any further import node-fetch constraints to consider, or are there any known AWS Lambda issues at the moment? I enabled our workflow to be accessible to you, so you can see our code and errors.
Thank you very much for your support
Hi @rodger1,
I see you have shared a workflow called Rodger with support, and I tried a test event and it executed properly.
Is there a particular step that is not working? If so could you tell me which?
Hi Guys, I’m having the same issue. I’ve clone a workflow that works fine, but the new version doesn’t .
I’ve already active the “Allow support…”
Workflow failed to build: 40b30601-de76-45a1-8b40-4893bf916514
Thanks 