Repository navigation
Conversation
Build the harness CLI with the fixture feature used by its runtimes, and correct the Lockr troubleshooting field.
dhruv8sh
left a comment
There was a problem hiding this comment.
Thanks for this. Strict field schemas for every known integration (enabled and disabled), the rejection of unknown IDs when validating or pushing, and the warn-and-continue behaviour at runtime are the right split. Configs already stored keep loading, and new typos are caught before deploy.
I checked:
deny_unknown_fieldsis not combined with#[serde(flatten)]on any config struct. The flattenedMaps intestlight.rsare on request and response bodies, notTestlightConfig, and the datadome flatten case was already handled.- Nested config structs are already strict (
JsAssetProxyAsset, and the datadome, prebid and aps sub-structs). validate_disabled_schemastill skips onlymissing fielderrors. Serde reports unknown fields while visiting the map, before it checks for missing ones, so minimal disabled blocks with a typo are rejected.deploy_validation_rejects_unknown_fields_in_minimal_disabled_integrationscovers this.- The
test-utilsfixture ID is gated, so production CLI builds keep the production ID list, and the EOF harness builds with the feature on. - The Lockr docs table matches
LockrConfig:app_idrequired withlength(min = 1),enableddefaulting to true, the TTL range of 60–86400, andrewrite_sdk_hostas a compatibility field.
The CHANGELOG and configuration guide spell out the push-config-first, deploy-binary-second migration clearly.
Two minor notes inline. Neither blocks merging.
ChristianPavilonis
left a comment
There was a problem hiding this comment.
Summary
The strict known-field schemas and deploy/runtime integration-ID handling are consistent with the intended contract. The rollout instructions need a Fastly propagation step to avoid activating strict validation against an older config blob.
The inline finding is prose-only because its documentation correction spans multiple files; no one-click suggestions are included.
Blocking
🔧 wrench
- Wait for Fastly config propagation before activating the strict binary — see inline at
docs/guide/configuration.md:192–196
Verification
All 21 changed files were read completely. git diff --check passed. Passing remote CI was reused rather than rerun locally. The propagation risk was source-traced through the pinned EdgeZero dependency; live Fastly propagation was not reproduced.
CI Status
- browser integration tests: PASS
- integration tests: PASS
- integration tests (Fastly EC lifecycle): PASS
- CodeQL: PASS
- cargo test (ts CLI, native) (macos-latest): PASS
- cargo test (axum native): PASS
- format-typescript: PASS (required)
- Analyze (javascript-typescript): PASS
- cargo check (cloudflare native + wasm32-unknown-unknown): PASS
- cargo fmt: PASS (required)
- HTML EOF runtime (Fastly): PASS
- Analyze (javascript-typescript): PASS
- Analyze (python): PASS
- cargo test: PASS (required)
- CLAUDE.md symlink guard: PASS
- format-docs: PASS (required)
- Analyze (rust): PASS
- docs-proposal scripts: PASS
- cargo check/build/test (spin native + wasm32-wasip1): PASS
- cargo test (cross-adapter parity): PASS
- cargo test (ts CLI, native) (ubuntu-latest): PASS
- prepare integration artifacts: PASS
- ts dev lint domains (changed lines): PASS
- vitest: PASS
- Analyze (actions): PASS
Require Fastly config propagation before strict binary activation. Keep only unknown/missing-field details in outer integration parse messages, retaining other serde details in the report cause chain. Document per-request unknown-ID warnings on ordinary Fastly sandboxes.
Summary
Known tables containing unknown fields will fail startup with the new binary. Run the new CLI's
ts config validate, correct the reported settings, push the cleaned config while the old binary runs. On Fastly, wait for the config-store propagation window to elapse before activating the new binary; a successful push does not mean every point of presence (POP) has the cleaned config.Changes
crates/trusted-server-core/src/config.rscrates/trusted-server-core/src/settings.rscrates/trusted-server-core/src/integrations/adserver_mock.rscrates/trusted-server-core/src/integrations/didomi.rscrates/trusted-server-core/src/integrations/google_tag_manager.rscrates/trusted-server-core/src/integrations/gpt.rscrates/trusted-server-core/src/integrations/js_asset_proxy.rscrates/trusted-server-core/src/integrations/lockr.rscrates/trusted-server-core/src/integrations/nextjs/mod.rscrates/trusted-server-core/src/integrations/permutive.rscrates/trusted-server-core/src/integrations/sourcepoint.rscrates/trusted-server-core/src/integrations/testlight.rscrates/trusted-server-core/src/test_support/async_html_finalization.rscrates/trusted-server-integration-tests/tests/html_eof_runtime.rscrates/trusted-server-cli/tests/config_env_overlay.rsdocs/guide/configuration.mddocs/guide/integrations/lockr.mdapp_id.docs/guide/error-reference.mdCHANGELOG.mddocs/superpowers/specs/2026-10-27-strict-integration-validation-design.mddocs/superpowers/plans/2026-10-27-strict-integration-validation.mdCloses
Closes #1201
Spec
Not a feature (bug fix). The technical design is in
docs/superpowers/specs/2026-10-27-strict-integration-validation-design.md.Test plan
Run with Rust 1.98.1, Node 24.20.0 and Viceroy 0.21.0. Initial sandbox listener/keychain-access failures were resolved by full reruns with the required local access.
cargo test-fastly && cargo test-axumcargo clippy-fastly && cargo clippy-axumcargo fmt --all -- --checkcd crates/trusted-server-js/lib && npx vitest run— 1,232 tests passed with one worker, no type errorscd crates/trusted-server-js/lib && npm run formatcd docs && npm run formatcargo test-fastly-reuse,cargo test-cloudflare,cargo test-spin./scripts/async-html-finalization-local-test.sh axum --auction./scripts/async-html-finalization-local-test.sh fastly --release --auction— includes the test-utils release WASM buildfastly compute serve— not performedRegressions distinguish the original acceptance/diagnostic failures and cover all 15 production integration IDs, enabled/disabled fields, runtime warnings, open payload maps and deprecated compatibility fields.
The EOF harness builds its CLI with
trusted-server-core/test-utilsso validation recognizes the fixture integration selected by its runtimes. Ordinary production CLI builds retain the production ID list.Checklist
unwrap()in production codelogmacros (notprintln!)