sst
Cannot deploy after updating from 0.1.111 ion to 3.1.49
When I started building my app I installed ion through specifying ion in the package.json and it was working fine.
However when I tried to deploy to prod I got this error: TypeError: pulumi.runtime.invokeOutput is not a function.
So I decided to update to the latest SST version. I ran pnpm update sst --latest and ran my usual dev command
sst dev --stage dev.
But now I get even more errors than I got previously only in prod.
| Error punchline-api sst:aws:ApiGatewayV1 → punchline-apiResourceBatmfh aws:apigateway:Resource
| sdk-v2/provider2.go:509: sdk.helper_schema: creating API Gateway Resource: operation error API Gateway: CreateResource, https response error Stat
usCode: 409, RequestID: 302b0167-98ba-4c2f-b5d2-faed40291a11, ConflictException: Another resource with the same parent already has this name: web: pro
[email protected]
| Error punchline-api sst:aws:ApiGatewayV1 → punchline-apiResourceBabtrc aws:apigateway:Resource
| sdk-v2/provider2.go:509: sdk.helper_schema: creating API Gateway Resource: operation error API Gateway: CreateResource, https response error Stat
usCode: 409, RequestID: e56654a1-b248-4347-a504-b700fa31925e, ConflictException: Another resource with the same parent already has this name: api: pro
[email protected]
| Error punchline-api sst:aws:ApiGatewayV1 → punchline-apiResourceBatmfh aws:apigateway:Resource
| Resource: operation error API Gateway: CreateResource, https response error StatusCode: 409, RequestID: 302b0167-98ba-4c2f-b5d2-faed40291a11, Confl
ictException: Another resource with the same parent already has this name: web
| Error punchline-api sst:aws:ApiGatewayV1 → punchline-apiResourceBabtrc aws:apigateway:Resource
| Resource: operation error API Gateway: CreateResource, https response error StatusCode: 409, RequestID: e56654a1-b248-4347-a504-b700fa31925e, Confl
ictException: Another resource with the same parent already has this name: api
✕ Failed
punchline-api sst:aws:ApiGatewayV1 → punchline-apiResourceBatmfh aws:apigateway:Resource
sdk-v2/provider2.go:509: sdk.helper_schema: creating API Gateway Resource: operation error API Gateway: CreateResource, https response error Stat
usCode: 409, RequestID: 302b0167-98ba-4c2f-b5d2-faed40291a11, ConflictException: Another resource with the same parent already has this name: web: pro
[email protected]
punchline-api sst:aws:ApiGatewayV1 → punchline-apiResourceBabtrc aws:apigateway:Resource
sdk-v2/provider2.go:509: sdk.helper_schema: creating API Gateway Resource: operation error API Gateway: CreateResource, https response error Stat
usCode: 409, RequestID: e56654a1-b248-4347-a504-b700fa31925e, ConflictException: Another resource with the same parent already has this name: api: pro
[email protected]
punchline-api sst:aws:ApiGatewayV1 → punchline-apiResourceBatmfh aws:apigateway:Resource
Resource: operation error API Gateway: CreateResource, https response error StatusCode: 409, RequestID: 302b0167-98ba-4c2f-b5d2-faed40291a11, Confl
ictException: Another resource with the same parent already has this name: web
punchline-api sst:aws:ApiGatewayV1 → punchline-apiResourceBabtrc aws:apigateway:Resource
Resource: operation error API Gateway: CreateResource, https response error StatusCode: 409, RequestID: e56654a1-b248-4347-a504-b700fa31925e, Confl
ictException: Another resource with the same parent already has this name: api
Its a conflict of some sort so I tried to change the name of the API Gateway but it did not fix the issue. Will I have to delete my entire deployment? Since I don't want to redo adding my SST secrets.
Same problem here trying to deploy this morning.
Failed
TypeError: pulumi.runtime.invokeOutput is not a function
at getAvailabilityZonesOutput (/..proj/.sst/platform/node_modules/@pulumi/getAvailabilityZones.ts:202:27)
at normalizeAz (file:///..proj/.sst/platform/src/components/aws/vpc.ts:166:21)
at new _Vpc (file:///..proj/.sst/platform/src/components/aws/vpc.ts:146:19)
at run (file:///..proj/sst.config.ts:14:17)
at run (file:///..proj/.sst/platform/src/auto/run.ts:33:26)
at file:///..proj/eval.ts:4:28
at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
at ModuleLoader.import (node:internal/modules/esm/loader:316:24)
Had a similar issue, downgrading the aws provider to 6.52.0 instead of the latest version 6.54.0 fixed the issue.
You can do this following the steps here - https://sst.dev/docs/providers/#versions
Thanks @JoshwJB - This got me moving again!
FWIW, attempting to push through with the upgrade from 0.1.111 to 3.1.49 caused a number of other problems for me. Notably, for some reason a bucket.subscribe function stopped working. Initially there was simply no trigger on the lambda. Removing an event filter (events: ["s3:ObjectCreated:*"]) set up the trigger. It still never actually fired though...
Rolling back to 0.1.111, and rolling back the aws provider has me sorted for now.
I'm undergoing this issue right now. I'm currently using sst 0.1.21, not sure why it is happening
| Error
| TypeError: pulumi.runtime.invokeOutput is not a function
| at getPartitionOutput (/home/runner/work/doutor-sim/doutor-sim/.sst/platform/node_modules/@pulumi/getPartition.ts:89:27)
| at normalizePartition (file:///home/runner/work/doutor-sim/doutor-sim/.sst/platform/src/components/aws/ssr-site.ts:195:12)
| at prepare (file:///home/runner/work/doutor-sim/doutor-sim/.sst/platform/src/components/aws/ssr-site.ts:173:21)
| at new Nextjs (file:///home/runner/work/doutor-sim/doutor-sim/.sst/platform/src/components/aws/nextjs.ts:497:45)
| at run (file:///home/runner/work/doutor-sim/doutor-sim/sst.config.ts:96:5)
| at run (file:///home/runner/work/doutor-sim/doutor-sim/.sst/platform/src/auto/run.ts:33:26)
| at file:///home/runner/work/doutor-sim/doutor-sim/eval.ts:6:28
| at ModuleJob.run (node:internal/modules/esm/module_job:234:25)
| at ModuleLoader.import (node:internal/modules/esm/loader:[47](https://github.com/mathuxbr/doutor-sim/actions/runs/11106117744/job/30856042755#step:8:48)3:24)
Edit: it works:
Had a similar issue, downgrading the aws provider to
6.52.0instead of the latest version6.54.0fixed the issue. You can do this following the steps here - https://sst.dev/docs/providers/#versions
I reverted to the 6.52.0 AWS provider on version 3.1.49 and still get the same conflict errors. I might try doing SST destroy to see if that resolves it.
Reverting back to 0.1.111 and using the 6.52.0 AWS provider fixed the TypeError: pulumi.runtime.invokeOutput is not a function error I got in GH Actions.
But the issue when migrating to 3.1.49 must be properly fixed, since reverting the AWS provider and staying on an old SST version isn't a good fix in the long run.
I
Had a similar issue, downgrading the aws provider to
6.52.0instead of the latest version6.54.0fixed the issue. You can do this following the steps here - https://sst.dev/docs/providers/#versions
This worked for me :pray:
It would be nice if someone could shed some light on what's happening here.
My CI suddenly broke without any dependency changes for two separate projects, one on an early 0.1.44 version, the other on 3.0.70, both due to the pulumi.runtime.invokeOutput is not a function TS error. I assume that a specific pulumi version was not pinned Properly for SST and the lockfile doesnt cover it either?
For the 0.1.44 project, upgrading to 3.1.54 worked without needing to specificy a different AWS provider version in the changelog. I wonder if the recent releases fixed something? I can't find anything in the changelogs.
For the project that was on 3.0.70, I tried upgrading to 3.1.51 first which also fixed the pulumi error, and tried to pin the aws provider version , but that did not work out. I tried 3.1.54, but that doesnt work either.
I always get the PreconditionFailed: The request failed because it didn't meet the preconditions in one or more request-header fields.: [email protected] (or version 6.xx.x) Error for different resources, for some resources also without a version.
I also tried pinning different versions like the v6.28.1 I was on the last deployment.
What's interesting now is, that sst now logs multiple versions during deployment:
~ Deploy
| Info Downloading provider aws v6.28.1
| Info Downloading provider aws v6.52.0
| Info Downloading provider aws v6.54.1
| Info Downloading provider aws v6.54.2
I believe these are not part of the commited code, so I assume SST stores these versions remotely in the S3 Bucket and fetches the required versions to match each resource? And for some reason that left my resources in some mixed state of versions? If that's the case, there's probably room for improvement here to check versions before partially altering resources, although i'm not sure if that's within the scope of SST or pulumi. I might be wrong here and there's something I overlooked that causes these different version?
Okay, turns out that the issue regarding PreconditionFailed actualy was due to some manually altered resource that diverged from state, which I managed to solve using sst refresh. I had manually edited some cloudfront function, and apparently recent versions switched from cloudfront-js-1.0 to cloudfront-js-2.0, causing that issue to surface.
Got the same conflict issue on my side:
Not sure how to move on from there. Destoying my stack is not an option.
