Fastly staged deploy drops deployment-supplied store-name mappings

[ChristianPavilonis]

Description

At EdgeZero revision 055f7e94e53f3b7d9551ae078db7f015930ba953, a Fastly staged deploy can drop a deployment-supplied logical-to-physical store-name mapping unless the same mapping already exists in the production runtime-env store in service-scoped form.

The deploy action received:

EDGEZERO__STORES__SECRETS__TRUSTED_SERVER_SECRETS__NAME=ts_secrets

However, ts deploy --adapter fastly --staging reconciled the staging twin without that mapping. The deployed application then tried to open the logical name trusted_server_secrets instead of the linked physical name ts_secrets and failed during startup.

Reproduction

1. Declare logical secret store trusted_server_secrets in edgezero.toml.

2. Link a physical Fastly Secret Store as ts_secrets.

3. Ensure the production edgezero_runtime_env store has either no mapping or only the legacy unscoped mapping. Do not add the service-scoped mapping.

4. Export:

   export EDGEZERO__STORES__SECRETS__TRUSTED_SERVER_SECRETS__NAME=ts_secrets

5. Run a staged Fastly deploy.

6. Inspect edgezero_runtime_env_staging_<SERVICE_ID>.

The staging twin contains the generated config selector but not:

EDGEZERO__SERVICES__<SERVICE_ID>__STORES__SECRETS__TRUSTED_SERVER_SECRETS__NAME=ts_secrets

In the observed deployment, reconciliation also deleted the legacy unscoped mapping from the staging twin.

Cause

staging_entries_from_production copies only current-service, service-scoped production entries and adds config selectors. It does not merge store-name mappings supplied through the deploy process environment. This is safe with respect to cross-service ownership, but it makes the documented deploy-time mapping ineffective when provision has not first migrated the production entry to service-scoped form.

Expected behavior

A staged deploy should persist deployment-supplied store-name mappings under the current service scope before linking the staging runtime-env store. It should not require a separate provisioning run when the deploy action already received the mapping.

Production deploys should preserve the same invariant so later staged deploys can mirror the scoped mapping.

Impact

The deploy and health check can appear successful while normal application startup fails when it first resolves a secret reference. The /health path may not exercise secret resolution.

Workaround

Upsert the service-scoped mapping into both the production runtime-env store and the current staging twin. Once production has the scoped entry, later staged deploys mirror it correctly.

Acceptance criteria

• A staged deploy with a non-default EDGEZERO__STORES__*__NAME value writes the corresponding service-scoped entry to the staging twin.
• The mapping works when production has no prior entry or only a legacy unscoped entry.
• Reconciliation does not delete a mapping supplied to the current deploy.
• A focused test covers the deploy-environment mapping plus service-scoped staging reconciliation.