Skip to content

Expose a public runtime-env EnvConfig API for custom Fastly entry points #349

Description

@aram356

Problem

edgezero-adapter-fastly resolves EDGEZERO__* runtime overrides from the version-linked edgezero_runtime_env Fastly Config Store in env_config_from_runtime_dictionary (src/lib.rs:177 at v0.0.6). That function is private and only reachable through run_app / the dispatch path.

A downstream app with a custom Fastly entry point (Trusted Server bypasses run_app and builds its app directly) cannot resolve those overrides without duplicating the store name, the key spellings, and the key-derivation rules — internals that can drift.

Consequence downstream

The Fastly staging lifecycle shipped in #316 relinks edgezero_runtime_env for a staged version and redirects EDGEZERO__STORES__CONFIG__<ID>__KEY to <id>_staging. Trusted Server's entry point resolves its config selectors via EnvConfig::from_env() (empty on Compute), so a staged version silently loads the production config blob — a staging healthcheck exercises the new binary against production config and can false-pass. Reported in IABTechLab/trusted-server#940 review.

Proposal

Export the runtime-env loader as public API from edgezero-adapter-fastly, e.g.

pub fn runtime_env_config(stores: StoresMetadata) -> EnvConfig

or a narrower helper that takes the logical store ids to resolve. Downstream custom entry points then resolve staged selectors identically to run_app, with one source of truth for the store name and key list.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions