`ServerlessDeploymentBucket` incorrectly removed from template when `deploymentBucket.name` is set on existing stacks

Issue description

I am reporting this first as an investigation issue because I do not yet have a clean minimal reproduction.

I observed a deployment failure that appears to be related to enableLegacyDeploymentBucket and deploymentBucket, but only for a specific long-lived existing stack with historical deployment bucket state.

At the moment, I cannot reproduce this from a fresh project.

What I know so far

• The issue happens when enableLegacyDeploymentBucket: true is enabled.
• Removing enableLegacyDeploymentBucket resolves the problem in my case.
• The affected stack is not a new stack. It is a long-lived existing stack.
• The affected upgrade path I observed was from Serverless Framework 4.4.19 to 4.33.3.
• The affected stack was originally created around 2022, during the v3 era.
• At the moment, I cannot reproduce this from a fresh project or from a setup I tested from around a year ago.

Important historical context

Historically, this service used a deployment bucket that was auto-generated by Serverless.

After a later upgrade, I had to explicitly configure deploymentBucket in order to keep using that same existing bucket.

So this is not a case where I started with a manually managed custom deployment bucket from the beginning. It is a case where an older, historically auto-generated deployment bucket is now being explicitly referenced through deploymentBucket.

This detail may be important to the issue.

Current config pattern

provider:
  deploymentBucket:
    name: <existing bucket name>

  enableLegacyDeploymentBucket: true

Observed behavior

While debugging, I found that this.deploymentBucketInStack becomes undefined in generate-core-template.js.

Because of that, Serverless enters the branch that removes deployment bucket resources from the generated CloudFormation template.

In my case, this results in unexpected behavior against the existing stack and causes deployment failure.

The relevant behavior seems to be that when deploymentBucketInStack is falsy in the userProvidedBucketName or related path, Serverless deletes:

• Resources.ServerlessDeploymentBucket
• Resources.ServerlessDeploymentBucketPolicy

Expected behavior

Serverless should correctly handle existing stacks that reuse a historically auto-generated deployment bucket via explicit deploymentBucket configuration.

It should not incorrectly enter the resource-removal path when the stack state is not being correctly resolved.

Workaround

Removing enableLegacyDeploymentBucket while keeping deploymentBucket.name set to the existing bucket resolves the issue in my environment.

Additional notes

I am not sure yet whether this is:

1. a bug specifically in enableLegacyDeploymentBucket handling for some existing v3-era stacks, or
2. a broader historical-state issue involving auto-generated deployment buckets that later had to be explicitly configured via deploymentBucket.

I am opening this issue first to document the observed behavior and investigate reproduction conditions before attempting a fix.

Potential impact: failed deployment may leave stack in an unrecoverable state

In my case, once the deployment failed, the CloudFormation stack entered UPDATE_ROLLBACK_COMPLETE state. After that, even rolling back to the previously working framework version (4.4.19) and configuration did not resolve the issue.

Subsequent deployments failed with:

The serverless deployment bucket "<bucket name>" does not exist.
Create it manually if you want to reuse the CloudFormation stack "<stack name>",
or delete the stack if it is no longer required.

The physical S3 bucket still existed, but the framework could no longer resolve it correctly. This may indicate that the failed deployment can corrupt the relationship between the CloudFormation stack's logical ServerlessDeploymentBucket resource and the physical S3 bucket in a way that CloudFormation rollback does not fully restore.

If this is the case, the issue could be more severe than a simple deployment failure — it may leave an existing stack in a state that requires manual intervention to recover.

Environment

• Framework Version: upgraded from 4.4.19 to 4.33.3

Context

No response