Repository navigation
Description
Description
crates/trusted-server-core/src/migration_guards.rs scans a hand-maintained list of include_str! source files for Fastly SDK references. An added core Rust file can escape the guard if nobody updates that list. The historical PR review that prompted this issue identified two unlisted DataDome files; the gap is broader now.
Reproducible evidence
At HEAD 666953a0d, a read-only inventory of crates/trusted-server-core/src/**/*.rs versus the include_str!("...rs") entries in migration_guards.rs found 26 unlisted files, excluding migration_guards.rs itself. These include integrations/datadome/protection.rs, integrations/datadome/protection_scope.rs, auction/openrtb.rs, cache_policy.rs, and config.rs. The count is a snapshot; recalculate it when implementing. The existing test scans only checked_sources(). The original issue refers to allowlisted_sources(), but no such function exists at this HEAD; ec/kv.rs and ec/rate_limiter.rs are present in checked_sources(). Confirm whether any source still needs an explicit SDK exception before adding an allowlist.
The original review also recorded a prototype in which build.rs generated a source inventory for an XOR membership test, including a passing negative case. It was reverted as too heavy for that PR; it is historical evidence, not a required design.
Expected behavior
Every core .rs source is checked for forbidden Fastly SDK use, except any explicitly justified SDK exception, and adding an unclassified file fails CI.
Actual behavior
Files absent from the hand-maintained inventory are not checked by this guard.
Proposed fix
Make the inventory complete and add a build-time or test-time completeness assertion that works under the wasm/Viceroy test target. Require each source to appear exactly once in the checked inventory or a justified exception set, if such a set is needed. Keep migration_guards.rs exempt because it contains the banned pattern in the guard itself. Choose the simplest mechanism that makes newly added files fail CI until classified.
Done when
- All current core
.rsfiles are classified exactly once, with any SDK exceptions explained. - A test fails when a new core
.rsfile is omitted, and fails when a file is listed twice. - The guard catches a Fastly SDK reference in a newly classified source.
- Target-matched Fastly tests and lint, plus formatting, pass.
Context
Follow-up from the review of feature/edgezero-pr15-remove-fastly-core.
Activity
aram356 commentedon Sep 24, 2026
Current state on main at a4e01eb.
migration_guards.rsnow has a single list.allowlisted_sources()was removed in #643 (00cf849), which movedec/kv.rsandec/rate_limiter.rsintochecked_sources(). That list names 97 files, all of which still exist. 25 of the 123.rsfiles undercrates/trusted-server-core/srcare not in it (excludingmigration_guards.rsitself). That is the two DataDome files named above plus 23 more:Integrations:
integrations/datadome/protection.rsintegrations/datadome/protection_scope.rsintegrations/js_asset_proxy.rsintegrations/osano.rsEverything else:
auction/openrtb.rsauction/openrtb/test_executor.rsauction/openrtb/tests.rsauction/plan.rsauction/profile.rsauction/routing.rsauction/telemetry.rscache_policy.rsconfig.rsconfig_payload.rscookies/template_cache_policy.rscreative_opportunities.rsec/admin.rsec/kv_backend.rsplatform/backend_naming.rsplatform/template_assembly.rsplatform/template_cache.rsprice_bucket.rsresponse_privacy.rssecret_resolution.rstester_cookie.rsTo regenerate the list from the repository root:
One point for the automation item: core no longer has a
fastlydependency on either target, so ause fastlyin any core file would fail to compile until someone adds the dependency back.The same holds for the host target. A CI step that fails when
fastlyappears in core's dependency graph covers every current and future file, needs no inventory and nobuild.rs, and avoids the wasmstd::fslimit mentioned above. The text scan would then only matter if the dependency came back.