Hi, I'm trying to deploy to a new account + enviro...
# sst
s
Hi, I'm trying to deploy to a new account + environment since updating to the latest version of sst but I'm running into problems with my frontend & database where they get stuck on custom SST resources for about an hour before rolling back as they were unable to proceed. I've detailed the errors below, I may try rolling back to an earlier version of SST to see if that resolves the errors, but if anyone has any insights I'm all ears. Frontend stack fails on Custom::SSTEdgeLambdaBucket:
Copy code
CREATE_FAILED | Custom::SSTEdgeLambdaBucket | EdgeLambdaBucket | CloudFormation did not receive a response from your Custom Resource. Please check your logs for requestId [43be6075-8550-4a85-91a3-e4227206f263]. If you are using the Python cfn-response module, 
you may need to update your Lambda function code so that CloudFormation can attach the updated version.
When looking into the cloud watch logs I find:
Copy code
undefined	ERROR	Uncaught Exception 	
{ "errorType": "Error", "errorMessage": "Must use import to load ES Module: /var/task/s3-bucket.js\nrequire() of ES modules is not supported.\nrequire() of /var/task/s3-bucket.js from /var/runtime/UserFunction.js is an ES module file as it is a .js file whose nearest parent package.json contains \"type\": \"module\" which defines all .js files in that package scope as ES modules.\nInstead rename s3-bucket.js to end in .cjs, change the requiring code to use import(), or remove \"type\": \"module\" from /var/task/package.json.\n", "code": "ERR_REQUIRE_ESM", "stack": [ "Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /var/task/s3-bucket.js", "require() of ES modules is not supported.", "require() of /var/task/s3-bucket.js from /var/runtime/UserFunction.js is an ES module file as it is a .js file whose nearest parent package.json contains \"type\": \"module\" which defines all .js files in that package scope as ES modules.", "Instead rename s3-bucket.js to end in .cjs, change the requiring code to use import(), or remove \"type\": \"module\" from /var/task/package.json.", "", " at Object.Module._extensions..js (internal/modules/cjs/loader.js:1015:13)", " at Module.load (internal/modules/cjs/loader.js:863:32)", " at Function.Module._load (internal/modules/cjs/loader.js:708:14)", " at Module.require (internal/modules/cjs/loader.js:887:19)", " at require (internal/modules/cjs/helpers.js:74:18)", " at _tryRequire (/var/runtime/UserFunction.js:75:12)", " at _loadUserApp (/var/runtime/UserFunction.js:95:12)", " 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:999:30)" ] }
Backend stack fails on Custom::SSTScript:
Copy code
CREATE_FAILED | Custom::SSTScript | ClusterMigrationResource0F3A2EDD | CloudFormation did not receive a response from your Custom Resource. Please check your logs for requestId [ad1c4d9e-6946-482e-bd9d-f18bb90f6610]. If you are using the Python cfn-response module, you may need to update your Lambda function code so that CloudFormation can attach the updated version
When looking into the cloud watch logs I find:
Copy code
ERROR	Invoke Error 	{"errorType":"SyntaxError","errorMessage":"Unexpected token 'export'","stack":["/var/task/sst_rds_migration_scripts/0001_setupAuthTables.js:1","export const up = async (db) => {","^^^^^^","","SyntaxError: Unexpected token 'export'","    at Object.compileFunction (node:vm:352:18)","    at wrapSafe (node:internal/modules/cjs/loader:1032:15)","    at Module._compile (node:internal/modules/cjs/loader:1067:27)","    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1155:10)","    at Module.load (node:internal/modules/cjs/loader:981:32)","    at Function.Module._load (node:internal/modules/cjs/loader:822:12)","    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:161:29)","    at ModuleJob.run (node:internal/modules/esm/module_job:195:25)","    at async Promise.all (index 0)","    at async ESMLoader.import (node:internal/modules/esm/loader:337:24)"]}
It looks like it's related to using ESM modules from the logs, but is this a limitation of SST?
f
Leaving a note here that this should be fixed in
v1.2.15