Problem
SST's physicalName() in platform/src/components/naming.ts silently truncates resource names when they exceed AWS per-type limits (e.g. Lambda's 64-char cap). The prefixName helper tries app+stage+name, then stage+name, then name-only, chopping the leftmost component to fit. No warning or error is emitted.
This is compounded by Pulumi's AWS provider auto-naming, which also silently truncates when SST doesn't set an explicit name: (the common case for sst.aws.Function).
The truncated name is frozen in Pulumi state at creation time. On subsequent app-name changes, the physical name never updates — leading to orphaned resources still routed through live API Gateway integrations, running stale code against production data.
We lost a full day to this. See our post-mortem for the gory details: 21 Lambdas stuck with names from 8 different truncated app-name variants, stale code running against live DynamoDB, midnight Slack alerts from code that no longer existed in the source tree.
Related closed issues: #4100, #4410
What Pulumi offers
Pulumi 3.x added pulumi:autonaming configuration:
config:
pulumi:autonaming:
pattern: ${name}-${hex(8)}
enforce: true
enforce: true makes the provider error instead of silently truncating. This is exactly the safety net needed.
The gap
SST generates the Pulumi project config dynamically. Only aws:*-prefixed keys are reachable through sst.config.ts via providers.aws.*. The pulumi:autonaming key is a top-level Pulumi config namespace and isn't exposed.
Even if enforce: true were reachable, it only covers the Pulumi auto-naming layer. SST's own physicalName() runs first and would still silently truncate.
Request
Either (or both):
- Expose
pulumi:autonaming config through sst.config.ts, e.g.:
return {
name: "myapp",
home: "aws",
providers: {
pulumi: { autonaming: { enforce: true } },
},
};
- Change
physicalName() / prefixName() to throw instead of silently truncating when the computed name exceeds the limit. If a resource name doesn't fit, the developer needs to know immediately — not discover it months later via orphaned resources.
Our workaround
We added manual guards (assertLambdaNameFits, assertCronNameFits, assertBucketNameFits) that compute the expected physical name using the same formula as SST and throw at deploy time if it overflows. Every new sst.aws.Function(...) call site must be preceded by a guard. It works, but it's a code smell — the infrastructure layer should enforce its own naming constraints.
Problem
SST's
physicalName()inplatform/src/components/naming.tssilently truncates resource names when they exceed AWS per-type limits (e.g. Lambda's 64-char cap). TheprefixNamehelper triesapp+stage+name, thenstage+name, thenname-only, chopping the leftmost component to fit. No warning or error is emitted.This is compounded by Pulumi's AWS provider auto-naming, which also silently truncates when SST doesn't set an explicit
name:(the common case forsst.aws.Function).The truncated name is frozen in Pulumi state at creation time. On subsequent app-name changes, the physical name never updates — leading to orphaned resources still routed through live API Gateway integrations, running stale code against production data.
We lost a full day to this. See our post-mortem for the gory details: 21 Lambdas stuck with names from 8 different truncated app-name variants, stale code running against live DynamoDB, midnight Slack alerts from code that no longer existed in the source tree.
Related closed issues: #4100, #4410
What Pulumi offers
Pulumi 3.x added
pulumi:autonamingconfiguration:enforce: truemakes the provider error instead of silently truncating. This is exactly the safety net needed.The gap
SST generates the Pulumi project config dynamically. Only
aws:*-prefixed keys are reachable throughsst.config.tsviaproviders.aws.*. Thepulumi:autonamingkey is a top-level Pulumi config namespace and isn't exposed.Even if
enforce: truewere reachable, it only covers the Pulumi auto-naming layer. SST's ownphysicalName()runs first and would still silently truncate.Request
Either (or both):
pulumi:autonamingconfig throughsst.config.ts, e.g.:physicalName()/prefixName()to throw instead of silently truncating when the computed name exceeds the limit. If a resource name doesn't fit, the developer needs to know immediately — not discover it months later via orphaned resources.Our workaround
We added manual guards (
assertLambdaNameFits,assertCronNameFits,assertBucketNameFits) that compute the expected physical name using the same formula as SST and throw at deploy time if it overflows. Everynew sst.aws.Function(...)call site must be preceded by a guard. It works, but it's a code smell — the infrastructure layer should enforce its own naming constraints.