sst refresh --stage fails with promise leaks during v3→v4 migration

[mikexavier]

Environment

• SST: 4.7.1 (from 3.17.10)
• @pulumi/aws: 7.20.0 (from 6.77.0)
• @pulumi/pulumi: 3.215.0
• Bun: 1.3.11, Node: 22, macOS

Issue

sst refresh --stage staging and --stage prod both exit with code 1 due to promise leaks. sst refresh --dev completes cleanly.

sst deploy is blocked by the migration check since refresh didn't complete.

Leaked resource types (via PULUMI_DEBUG_PROMISE_LEAKS=true)

• aws:lambda/function:Function
• aws:lambda/functionUrl:FunctionUrl
• aws:lambda/functionEventInvokeConfig:FunctionEventInvokeConfig
• aws:lambda/permission:Permission
• aws:s3/bucketPolicy:BucketPolicy
• aws:iam/rolePolicy:RolePolicy
• pulumi-nodejs:dynamic:Resource (KvKeys)

Stack traces originate from function.ts:2668 inside apply(async ...) at function.ts:1888.

Stack composition

Astro (×2), Nextjs (×1), StaticSite (×1), Function (×12), Cron (×9), Queue (×12), SnsTopic (×3), ApiGatewayWebSocket (×1), Router (×4), Postgres (×2), Dynamo (×10), Email (×1), Vpc (×1).

Possibly related

• Promise leak detected in Aws.KvKeys during Nextjs deploy/resource replacement #6470 / Fix Pulumi promise leak in KvKeys during site deploys #6479 — same apply(async ...) pattern fixed in site-builder.ts
• Pulumi dangling promises when using Service components in sst diff mode #6605 / Fix dangling promises in sst diff with Service component #6606 — same pattern fixed in container-builder.ts

Additional context

• This stack deployed without issues on SST 3.17.10
• sst diff --stage staging evaluates all resources and shows correct changes before the promise leak exits the process
• Tested disabling the $transform below — same result

$transform(sst.aws.Function, (args) => {
  args.runtime ??= 'nodejs22.x';
  args.nodejs = { ...args.nodejs, sourcemap: true };
  args.environment = $output(args.environment).apply((env) => {
    // adds --enable-source-maps to NODE_OPTIONS
  });
});

Current state

• Dev: sst refresh --dev completed. sst deploy failed — attempted to create new RDS instances instead of updating existing ones.
• Staging: sst refresh --stage staging failed (promise leaks). Attempted sst deploy which partially completed — deleted v3 resources but did not create v4 replacements. Staging sites are down (empty KvStore, missing server functions).
• Prod: sst refresh --stage prod failed (promise leaks). Deploy not attempted. Prod is running on v3-deployed resources but state is now v7 format. Cannot deploy with v3 or v4.

I'd appreciate some guidance on how to safely deploy to prod given the v7 state and the promise leak blocking the migration.

Separate: Bun catalog: protocol

nodejs.install copies literal "catalog:" into Lambda build package.json. npm install fails. Workaround: explicit versions for affected packages.

[vimtor]

@mikexavier sorry you faced this

in #6718 i fixed the catalog issue for pnpm. i've just created #6725 to track both pnpm and bun

the pulumi promise leaks are tricky to solve. for the moment, can you try upgrading to 4.6.4 instead? you won't face the catalog issue, which may be interfering

[mikexavier]

Thanks for the speedy response @vimtor !

I tried 4.6.4 with catalog: workaround removed — and getting the same 960 promise leaks on sst refresh --stage staging.

[mikexavier]

Spinning my wheels on this one @vimtor ...

Update: staging refresh now works, but site builds never run

I got past the promise leak issue by patching debuggable.js to filter Pulumi's internal transferProperty/resolveURN/etc promises from the leak detector. sst refresh --stage staging now completes successfully.

However, sst deploy never triggers site builds. Lambda functions build and deploy fine, but zero site builds run — no astro build, next build, or vite build ever executes.

I'm seeing

• sst deploy --print-logs shows esbuild running for all ~50 Lambda functions, but no site builds (astro build, next build, vite build) ever execute
• Pulumi state has the site components (Astro, Nextjs, StaticSite) and their AWS children (S3, CloudFront, KVStore), but appears to be missing Builder (local.Command) and KvKeys (pulumi-nodejs:dynamic:Resource) resources

I've tried

1. Adding a dummy env var (SST_REBUILD: '1') to all site environments — no effect
2. Clearing all build artifacts (.sst/artifacts, dist/, .next/, .open-next/) — no effect
3. Deleting entire .sst/ directory, reinstalling, redeploying — no effect
4. sst state repair --stage staging — "No changes made"
5. sst state remove outdoor-frontend-staging → redeploy — fails with CNAMEAlreadyExists on CloudFront distribution

Qs

1. Is there a supported way to force site rebuilds after a v3→v4 migration?
2. What's the recommended recovery path when state has the site components but is missing their Builder/KvKeys children?

[vimtor]

can you share a snippet of your sst.config.ts showing how you define your sites?

[mikexavier]

sst.config.ts:

export default $config({
  app(input) {
    return {
      name: 'outdoor',
      home: 'aws',
      providers: { aws: { region: 'eu-central-1', /* ... */ } },
      removal: input?.stage === 'prod' ? 'retain' : 'remove',
      protect: ['prod'].includes(input?.stage),
    };
  },
  async run() {
    $transform(sst.aws.Function, (args) => {
      args.runtime ??= 'nodejs22.x';
      args.nodejs = { ...args.nodejs, sourcemap: true };
      args.environment = $output(args.environment).apply((env) => ({
        ...env,
        NODE_OPTIONS: '--enable-source-maps',
      }));
    });
    await import('./infra');
    return {};
  },
});

infra/frontend.ts — Astro:

export const frontend = new sst.aws.Astro(`outdoor-frontend-${STAGE}`, {
  dev: { title: 'frontend-dev' },
  domain: FRONTEND_DOMAIN_CONFIG,
  environment: frontendEnv, // ~25 keys, mix of strings + Secret.value
  link: frontendLinks, // email, dynamoDB tables, secrets
  path: 'packages/frontend',
  permissions: [/* sts:AssumeRole for dev/staging */],
  transform: { server: (args) => { args.runtime = 'nodejs22.x'; } },
});

infra/cms.ts — Next.js (with VPC for RDS):

export const cms = new sst.aws.Nextjs(`outdoor-cms-${STAGE}`, {
  dev: { title: 'cms-dev' },
  domain: CMS_DOMAIN_CONFIG,
  environment: cmsEnv, // ~30 keys
  link: cmsLinks, // ~30 items: secrets, RDS, dynamo, queue, frontend, etc.
  path: 'packages/cms',
  permissions: [/* logs, cloudwatch, ce, sqs, s3, dynamodb, sts */],
  server: { install: ['sharp'], timeout: '2 minutes', memory: '2048 MB' },
  vpc,
  transform: {
    server: (args) => {
      args.runtime = 'nodejs22.x';
      args.concurrency = { reserved: IS_PROD ? 60 : 15 };
    },
  },
});

infra/brand.ts — Astro:

export const brand = new sst.aws.Astro(`outdoor-brand-${STAGE}`, {
  dev: { title: 'brand-dev' },
  domain: BRAND_DOMAIN_CONFIG,
  environment: brandEnv, // 5-6 keys
  link: brandLinks, // [email, sessionTable, BETTER_AUTH_SECRET]
  path: 'packages/brand',
  transform: { server: (args) => { args.runtime = 'nodejs22.x'; } },
});

infra/inbox/site.ts — Vite SPA:

export const inboxSite = new sst.aws.StaticSite(`outdoor-inbox-${STAGE}`, {
  path: 'packages/inbox',
  build: { command: 'bun run build', output: 'dist' },
  domain: INBOX_DOMAIN_CONFIG,
  environment: { /* VITE_WS_URL, VITE_API_URL, VITE_AUTH_URL, etc. */ },
  dev: {
    command: 'bun run dev',
    directory: 'packages/inbox',
    title: 'inbox-dev',
    autostart: true,
    url: 'http://localhost:5173',
  },
});

[mikexavier]

Quick FYI — appreciate both PRs! The catalog fix is working and for the AppSync fix, I tested 4.7.3 on staging without our workaround patch and we're still seeing the same ~960 promise leaks on sst refresh. Sticking with our patch for now. Just wanted to share in case it helps.