Read the Fastly config entry under its logical ID on every target

Move the EdgeZero pin from 657bfdcb to 74207863. Upstream fixed the Fastly
config key to the logical store ID for production, staging, and local
Viceroy alike, removing the `_staging` suffix and `store_key_for_target`.
Staging isolation now comes only from the physical Config Store the staging
environment selects.

Replace `RuntimeStoreConfig::for_target(staging)` with `logical()`, drop
the staging signal from both entry points, and update the CLI guide, spec,
and plan to describe the fixed key.

Author: aram356

Cargo.lock

@@ -92,14 +92,12 @@ use crate::rate_limiter::{FastlyRateLimiter, RATE_COUNTER_NAME};
 use edgezero_adapter_fastly::context::FastlyRequestContext;
 use edgezero_core::app::{App, Hooks, StoreMetadata, StoresMetadata};
 use edgezero_core::context::RequestContext;
-use edgezero_core::env_config::EnvConfig;
 use edgezero_core::error::EdgeError;
 use edgezero_core::http::{
     HandlerFuture, HeaderValue, Method, Request, Response, StatusCode, header,
 };
 use edgezero_core::router::RouterService;
 use error_stack::Report;
-use fastly::compute_runtime;
 use trusted_server_core::auction::AuctionTelemetrySink;
 use trusted_server_core::auction::endpoints::handle_auction;
 use trusted_server_core::auction::{
@@ -162,20 +160,17 @@ pub(crate) struct RuntimeStoreConfig {
 }
 
 impl RuntimeStoreConfig {
-    /// Store bindings for the running Fastly publication target.
+    /// Store bindings for the Fastly runtime.
     ///
     /// Fastly Compute has no process environment. `EdgeZero` links each selected
     /// physical store to the service version under its logical ID, so the
-    /// runtime opens stores by logical ID and derives the config entry key from
-    /// the target alone: production reads `<id>`, staging reads `<id>_staging`.
-    pub(crate) fn for_target(staging: bool) -> Self {
+    /// runtime opens stores by logical ID and reads the config entry under
+    /// that same ID for every publication target. Staging isolation comes from
+    /// linking a different physical store, never from a different key.
+    pub(crate) fn logical() -> Self {
         Self {
             config_store_name: StoreName::from(DEFAULT_CONFIG_STORE_ID),
-            config_key: EnvConfig::default().store_key_for_target(
-                "config",
-                DEFAULT_CONFIG_STORE_ID,
-                staging,
-            ),
+            config_key: DEFAULT_CONFIG_STORE_ID.to_owned(),
             secret_store_name: StoreName::from(DEFAULT_SECRET_STORE_ID),
         }
     }
@@ -1353,7 +1348,7 @@ impl Hooks for TrustedServerApp {
     }
 
     fn routes() -> RouterService {
-        let stores = RuntimeStoreConfig::for_target(compute_runtime::is_staging());
+        let stores = RuntimeStoreConfig::logical();
         Self::router_with_state(&stores).0
     }
 
@@ -1463,17 +1458,8 @@ mod tests {
     }
 
     #[test]
-    fn runtime_store_config_reads_the_staging_config_key_on_staging() {
-        let stores = RuntimeStoreConfig::for_target(true);
-
-        assert_eq!(stores.config_store_name.as_ref(), "trusted_server_config");
-        assert_eq!(stores.config_key, "trusted_server_config_staging");
-        assert_eq!(stores.secret_store_name.as_ref(), "trusted_server_secrets");
-    }
-
-    #[test]
-    fn runtime_store_config_opens_logical_store_ids_in_production() {
-        let stores = RuntimeStoreConfig::for_target(false);
+    fn runtime_store_config_opens_logical_store_ids_and_key() {
+        let stores = RuntimeStoreConfig::logical();
 
         assert_eq!(stores.config_store_name.as_ref(), "trusted_server_config");
         assert_eq!(stores.config_key, "trusted_server_config");

crates/trusted-server-adapter-fastly/src/app.rs

@@ -8,7 +8,6 @@ use edgezero_core::error::EdgeError;
 use edgezero_core::http::{Request as HttpRequest, Response as HttpResponse};
 use edgezero_core::response::IntoResponse;
 use error_stack::Report;
-use fastly::compute_runtime;
 use fastly::http::Method as FastlyMethod;
 use fastly::{Request as FastlyRequest, Response as FastlyResponse};
 
@@ -89,7 +88,7 @@ fn main() {
 
 /// Handles a request through the `EdgeZero` router path.
 fn edgezero_main(mut req: FastlyRequest) {
-    let runtime_stores = RuntimeStoreConfig::for_target(compute_runtime::is_staging());
+    let runtime_stores = RuntimeStoreConfig::logical();
 
     // Short-circuit the JA4 debug probe before app construction. Must run here
     // because TLS/JA4 accessors are only available on FastlyRequest before

crates/trusted-server-adapter-fastly/src/main.rs

@@ -131,29 +131,29 @@ ts deploy --adapter fastly --service-id <service-id> --application-release <rele
 
 A staged deploy selects the physical Config Store from the staging environment
 and links it to the staged version under the logical store ID. The staged
-runtime reads the `<logical-store-id>_staging` key from that store. It does not
-copy the production config blob there. Push the staged config before probing
-the staged version:
+runtime reads the `<logical-store-id>` key from that store. It does not copy
+the production config blob there. Push the staged config before probing the
+staged version:
 
 ```bash
 ts config push --adapter fastly --staging
 ts config diff --adapter fastly --staging
 ```
 
-Config keys are deterministic on Fastly: production reads `<logical-store-id>`,
-staging reads `<logical-store-id>_staging`, and local Viceroy reads the
-production key. The binary decides which key to read from Fastly's staging
-signal, not from a stored selector. Production and staging may select the same
-physical Config Store or different stores. After `ts config push --staging`,
-the staged binary reads `<logical-store-id>_staging` in the store selected by
-the staging environment, while the active production version continues to read
-its production key and store.
+The config key is fixed on Fastly: production, staging, and local Viceroy all
+read `<logical-store-id>`. Staging isolation comes from the physical store the
+staging environment selects with `EDGEZERO__STORES__CONFIG__<ID>__NAME`, never
+from a different key. Production and staging may select the same physical
+Config Store or different stores. After `ts config push --staging`, the staged
+binary reads `<logical-store-id>` in the store selected by the staging
+environment, while the active production version continues to read the same
+key in its own store.
 
 `--staging` on `config push` / `config diff` writes and compares the
-`<logical-store-id>_staging` key in the physical store selected by the staging
-environment. It is mutually exclusive with `--key`: the staging key is derived
-from the store's logical id, so an explicit key would be written where nothing
-reads it.
+`<logical-store-id>` key in the physical store selected by the staging
+environment. It is mutually exclusive with `--key`: Fastly accepts only the
+logical store ID as the key for every target, so an explicit key would be
+written where nothing reads it.
 
 Inspect and verify deployments with the deploy lifecycle commands. All three are
 Fastly-only — the axum, cloudflare, and spin adapters reject them:

docs/guide/cli.md

@@ -14,7 +14,7 @@
 
 - `Cargo.toml`: select the EdgeZero PR 381 branch for all EdgeZero crates.
 - `Cargo.lock`: lock all EdgeZero packages to the branch revision.
-- `crates/trusted-server-adapter-fastly/src/main.rs`, `crates/trusted-server-adapter-fastly/src/app.rs`: open stores by logical ID and derive the config key from Fastly's staging signal instead of reading `edgezero_runtime_env`.
+- `crates/trusted-server-adapter-fastly/src/main.rs`, `crates/trusted-server-adapter-fastly/src/app.rs`: open stores and the config entry by logical ID instead of reading `edgezero_runtime_env`.
 - `fastly.toml`: expose the local Viceroy secret store under its logical ID and drop the runtime selector store.
 - `crates/trusted-server-integration-tests/fixtures/configs/viceroy-template.toml`, `scripts/template-cache-local-test.sh`: keep generated Viceroy configurations aligned with the root Fastly configuration.
 - `crates/trusted-server-integration-tests/tests/common/config.rs`: regress the logical-ID store exposure in both Viceroy configurations.
@@ -131,11 +131,10 @@ compiler failure, make only the call-site changes required by that error and add
 a focused parsing or behavior test before the production edit.
 
 The branch head removes `edgezero_adapter_fastly::runtime_env_config`. Replace
-`RuntimeStoreConfig::from_env` with `RuntimeStoreConfig::for_target(staging)`:
-open `trusted_server_config` and `trusted_server_secrets` by logical ID and
-derive the config key with `EnvConfig::store_key_for_target`. Both entry points
-pass `fastly::compute_runtime::is_staging()`. Cover the production and staging
-keys with unit tests in `app.rs`.
+`RuntimeStoreConfig::from_env` with `RuntimeStoreConfig::logical()`: open
+`trusted_server_config` and `trusted_server_secrets` by logical ID and read
+the config entry under `trusted_server_config` for every target. Cover the
+logical IDs and key with a unit test in `app.rs`.
 
 - [ ] **Step 3: Verify the lockfile revision is consistent**
 
@@ -193,11 +192,10 @@ contract:
 
 - [ ] **Step 2: Update staging CLI guidance**
 
-Clarify that `ts config push --staging` writes the staging key into the physical
-Config Store selected by the staging environment, and that the staged binary
-reads `<logical-store-id>_staging` because Fastly reports it as staged, not
-because of a stored selector. State that production and staging may select the
-same or different physical stores.
+Clarify that `ts config push --staging` writes the logical key into the
+physical Config Store selected by the staging environment, and that the staged
+binary reads the same `<logical-store-id>` key there. State that production and
+staging may select the same or different physical stores.
 
 - [ ] **Step 3: Check for stale service-scoped guidance**
 

docs/superpowers/plans/2026-09-16-edgezero-fastly-store-selectors.md

@@ -27,9 +27,9 @@ the release tag that contains the merged change.
 
 The Fastly entry point will stop reading `edgezero_runtime_env`. It will open
 the config and secret stores by their logical IDs, `trusted_server_config` and
-`trusted_server_secrets`, and derive the config entry key from Fastly's staging
-signal through EdgeZero's target-key rule: production reads
-`trusted_server_config`, staging reads `trusted_server_config_staging`.
+`trusted_server_secrets`, and read the config entry under
+`trusted_server_config` for every target. Staging isolation comes from the
+physical store the staging environment selects, not from a different key.
 
 Local Viceroy configuration will expose the secret store under the logical ID
 `trusted_server_secrets` and drop the `edgezero_runtime_env` Config Store, so