Upgrading from 2.44.3 to 2.45.0 causes deployment failure

[leanderiversen]

Hi,

We are currently running our website using SST 2.44.3 and OpenNext 3.1.3 , and would like to upgrade to the latest V2 version of SST. After debugging this as best as I can, I have found that the upgrade from 2.44.3 to 2.45.0 or above causes UPDATE_FAILED Received response status [FAILED] from custom resource. Message returned: socket hang up for site/defaultServerFunction/AssetReplacer Custom::AssetReplacer and site/RevalidationProvider/framework-onEvent AWS::Lambda::Function.

We have also tried a combination of the latest V2 versions of SST and OpenNext to see if would play nice, but it does not seem like the case.

Do you have any ideas as to why this is happening?

Thank you!

[brentrager]

@leanderiversen I ran into this and tracked down the issue.

The problem arises from cthackers/adm-zip#548. I was able to fork this repo, pin adm-zip at 0.5.14, build sst, and patch my repo's version of sst 2.47.0 with the rebuilt version of support/custom-resources/index.mjs. A little complicated but it does fix the problem! If I have some more time I'll put up a PR.

[Gr33nLight]

Hello,
running into this issue as well, I'm on sst 2.47.0, is there a workaround that doesn't involve rebuilding and patching sst 😅 ?
Thank you!

@brentrager

[brentrager]

@Gr33nLight I do not know of another solution besides what I described yet, no.

https://github.com/SmooAI/sst-v2

There is my fork for the record.

There's an open PR that should fix it if the SST team merges and releases - #34

[Gr33nLight]

Thanks, I can't use a forked version of sst at the moment but I'm hoping it gets merged soon.

[fwang]

Released in v2.47.1

[TobiasMaehl-pIX]

Still getting the same error with v2.47.1

Looks like this from @brentrager's fork could be the fix?

[leanderiversen]

I have not had this specific issue happen since 2.47.1, but it could be that another dependency is installing a newer version, which is the one being used. I'm not sure though, but I can't say that this has happened since.

[meashishsaini]

Still getting the same error with v2.47.1

Looks like this from @brentrager's fork could be the fix?

I had the same issue. Patching this change through pnpm allowed me to deploy again.

[wpoynter]

I have run in to the same issue, I have just done a major upgrade of Next from 14 to 15 and with that upgraded SST too.

My current versions are

SST: v2.47.2
Next.js version : 15.1.7
OpenNext v3.2.2

I have confirmed the version of adm-zip

├─ sst@npm:2.47.2
│  └─ adm-zip@npm:0.5.14 (via npm:0.5.14)

I am struggling to tease out the underlying cause. There is mention of timing out. The file in question is around 50MB and I have checked the bucket, there are plenty of much larger files uploaded.

[wpoynter]

In the end, I got everything working again using yarn patch sst, I created the following patch which has solved the issue

diff --git a/support/custom-resources/index.mjs b/support/custom-resources/index.mjs
index e3cd5430b98b9a232d7d50300921c768b301fdb8..8e2f6d2c4298e1b831bd02342b20dfca58fd837b 100644
--- a/support/custom-resources/index.mjs
+++ b/support/custom-resources/index.mjs
@@ -132567,11 +132567,12 @@ async function download(bucket, key) {
 }
 async function upload(bucket, key) {
   console.log("upload");
+  const fileBuffer = fs.readFileSync(zipPath);
   await s3.send(
     new import_client_s3.PutObjectCommand({
       Key: key,
       Bucket: bucket,
-      Body: fs.createReadStream(zipPath)
+      Body: fileBuffer
     })
   );
 }

[leanderiversen]

@wpoynter The same fix is in pull request #43, but waiting for it to be merged.