Hey guys, think this one will be for <@U01JVDKASAC...
# help
b
Hey guys, think this one will be for @Frank and @thdxr, think I’m super close to getting this RDS thing licked but looks like my migrations didn’t run on deployment (I’m doing an actual deploy, not a
start
). Got the following error in CloudWatch:
Copy code
ERROR	[Error: EROFS: read-only file system, copyfile '/var/task/sst_rds_migration_scripts/000001_create_tables.js' -> '/var/task/sst_rds_migration_scripts/000001_create_tables.js1646905935564.js'] {
  errno: -30,
  code: 'EROFS',
  syscall: 'copyfile',
  path: '/var/task/sst_rds_migration_scripts/000001_create_tables.js',
  dest: '/var/task/sst_rds_migration_scripts/000001_create_tables.js1646905935564.js'
}
Currently Googling, any ideas?
Logs in the migration handler don’t look right either:
Copy code
2022-03-10T15:10:11.100Z	INFO	[provider-framework] user function response: 
{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST",
    "Payload": "{\"error\":{\"errno\":-2,\"code\":\"ENOENT\",\"syscall\":\"stat\",\"path\":\"/var/task/sst_rds_migration_scripts/000001_create_tables.js1646925011075.js\"}}"
}


2022-03-10T15:10:11.100Z	INFO	[provider-framework] submit response to cloudformation 
{
    "Status": "SUCCESS",
    "Reason": "SUCCESS",
    "StackId": "arn:aws:cloudformation:REGION:ACCOUNT:stack/STACK_NAME/97c0d600-a083-11ec-8257-0a9302a2837e",
    "RequestId": "6e505524-bc7b-4867-b80a-74ef74889872",
    "PhysicalResourceId": "6e505524-bc7b-4867-b80a-74ef74889872",
    "LogicalResourceId": "databaseMigrationResourceAC7A430C"
}
t
ah looks like the cache busting work I did has an issue
I'll figure out how to fix this today
b
Thanks man, appreciated 🙂 Feels like I’ve made more progress on this avenue in half hour than I did with rolling the Kysely stuff myself 😂🔫
t
haha that's what I hope for
ok I opened a PR, waiting for tests and will merge + release
b
Checked out the new release, getting the same error 😞 Going to clear down the stack, clear .build and .sst folders and try it again.
j
@Brinsley just checking if that helped.
b
The fix from the newer release worked, still might be worth looking in to that error handling stuff though; when a migration fails the execution lambda will respond with non-2xx status code and associated error message but the migration handler reports a success (200) as shown in the log output above. Might well be by design, just makes it difficult to troubleshoot issues with migrations.
f
Oh I see. @Brinsley just to clarify, u mean when the actual migration fails, the migration handler still succeeds, and hence CloudFormation continue to deploy?
b
Yea. Not sure if that's by design but it suppresses the error - couldn't see any errors logged to the migration function, only in the migration handler. They might be two separate issues.
f
Got it. Opened an issue for this, will look into this https://github.com/serverless-stack/serverless-stack/issues/1563