Skip to content

Reject unknown integration configuration IDs and fields - #1455

Open
prk-Jr wants to merge 5 commits into
mainfrom
fix/unknown-integration-config
Open

prk-Jr wants to merge 5 commits into
mainfrom
fix/unknown-integration-config

Conversation

@prk-Jr

@prk-Jr prk-Jr commented Oct 27, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

  • Reject unknown integration IDs during config validate/push and name unknown fields, preventing typos from silently changing integration behavior.
  • Apply strict known-field schemas to enabled and disabled integration blocks, tester-cookie settings and Tinybird, while preserving minimal disabled blocks, open payload maps and explicit compatibility fields.
  • Warn and continue at runtime for unknown integration IDs; document the cleanup-before-deploy migration for unknown fields.

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

File Change
crates/trusted-server-core/src/config.rs Reject unknown IDs at deploy validation, warn at runtime, and cover every known integration schema.
crates/trusted-server-core/src/settings.rs Include unknown/missing-field details in outer parse-error contexts, retain other serde details in the report cause chain, and make tester-cookie and Tinybird schemas strict.
crates/trusted-server-core/src/integrations/adserver_mock.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/didomi.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/google_tag_manager.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/gpt.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/js_asset_proxy.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/lockr.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/nextjs/mod.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/permutive.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/sourcepoint.rs Reject unknown configuration fields.
crates/trusted-server-core/src/integrations/testlight.rs Reject unknown configuration fields.
crates/trusted-server-core/src/test_support/async_html_finalization.rs Keep the optional fixture schema consistent with strict integration validation.
crates/trusted-server-integration-tests/tests/html_eof_runtime.rs Build the harness CLI with the fixture feature so strict validation accepts the test integration used by the runtime.
crates/trusted-server-cli/tests/config_env_overlay.rs Exercise actual validate/push refusal and verify no invalid local blob is written.
docs/guide/configuration.md Explain field validation, runtime ID warnings and safe upgrade order.
docs/guide/integrations/lockr.md Replace unsupported fields with the actual schema and defaults; align troubleshooting with app_id.
docs/guide/error-reference.md Use an existing integration and supported route in the troubleshooting example.
CHANGELOG.md Document the compatibility break and config-first cleanup order.
docs/superpowers/specs/2026-10-27-strict-integration-validation-design.md Record behavior, alternatives and preservation requirements.
docs/superpowers/plans/2026-10-27-strict-integration-validation.md Record implementation and verification steps.

Closes

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-axum
  • cargo clippy-fastly && cargo clippy-axum
  • cargo fmt --all -- --check
  • JS tests: cd crates/trusted-server-js/lib && npx vitest run — 1,232 tests passed with one worker, no type errors
  • JS format: cd crates/trusted-server-js/lib && npm run format
  • Docs format: cd docs && npm run format
  • Remaining adapter/host Clippy gates, including Cloudflare WASM, Spin native/WASM, CLI and codegen
  • cargo test-fastly-reuse, cargo test-cloudflare, cargo test-spin
  • Full host-target CLI suite, native core suite and feature-on core configuration tests
  • Integration parity and native template-build-digest tests/lint
  • JS build, Markdown formatting, WASM clock lint and documentation-proposal script checks
  • EOF harness native unit tests and Clippy
  • ./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 build
  • Manual fastly compute serve — not performed

Regressions 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-utils so validation recognizes the fixture integration selected by its runtimes. Ordinary production CLI builds retain the production ID list.

Checklist

  • Not a feature; feature-specific spec-review requirement is inapplicable
  • Changes follow AGENTS.md conventions
  • No unwrap() in production code
  • Uses log macros (not println!)
  • New code has tests
  • No secrets or credentials committed

@prk-Jr prk-Jr self-assigned this Oct 27, 2026
Build the harness CLI with the fixture feature used by its runtimes, and correct the Lockr troubleshooting field.
@aram356 aram356 added this to the 202611 milestone Oct 27, 2026
@prk-Jr
prk-Jr marked this pull request as ready for review October 29, 2026 12:11

@dhruv8sh dhruv8sh left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_fields is not combined with #[serde(flatten)] on any config struct. The flattened Maps in testlight.rs are on request and response bodies, not TestlightConfig, 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_schema still skips only missing field errors. 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_integrations covers this.
  • The test-utils fixture 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_id required with length(min = 1), enabled defaulting to true, the TTL range of 60–86400, and rewrite_sdk_host as 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 ChristianPavilonis left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread docs/guide/configuration.md Resolved
@prk-Jr
prk-Jr marked this pull request as draft October 29, 2026 16:46
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.
@prk-Jr
prk-Jr marked this pull request as ready for review October 29, 2026 17:10

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unknown integration IDs and fields in [integrations.*] pass validation and are ignored

4 participants