Repository navigation
List linked modules in each adapter - #1384
Open
jwrosewell wants to merge 58 commits into
Open
jwrosewell wants to merge 58 commits into
jwrosewell wants to merge 58 commits into
Conversation
The mock ad server moves from crates/ad-server/mock to crates/ad-server/iabtl, the stack's own, under the package name trusted-server-ad-server-iabtl. The module name is ad-server.iabtl, so a deployment that selected it writes [ad-server] module = "iabtl" and [ad-server.iabtl], and an implementation line names ad-server.iabtl. The workspace, the cargo aliases, the stock module list, the guide, the template and the changelog follow. The crate's types and log labels keep the word mock because they describe what the ad server does, which is to ask mocktioneer's decision endpoint.
The test fixture that proves the integration seam from outside core moves from crates/testing/seam-probe to crates/testing/iabtl, under the package name trusted-server-testing-iabtl. Its module name follows its folder, so the settings that select it and each of the modules it supplies write testing.iabtl, its shared table is [shared.iabtl], its loading cache is loading-cache.iabtl and the cache it declares is iabtl-answers. The two adapters' round-trip tests, the workflow that runs the crate's own tests, the guide and the changelog follow. The probe's integration id, its routes, the markers it writes into a page and the identities its modules answer with keep the words seam probe, because they say what the fixture is rather than where it lives.
The module that adds a publisher's sellers to ads.txt moves from crates/ads-txt/sellers to crates/ads-txt/iabtl, the stack's own initial version, under the package name trusted-server-ads-txt-iabtl. Its module name follows its folder, so a deployment that selected it writes [ads-txt] modules = ["iabtl"] and [ads-txt.iabtl], and the [[fetch]] entry on /ads.txt names the middleware ads-txt.iabtl. The workspace, the cargo aliases, the stock module list, the guide, the template and the changelog follow. The crate's types keep the word sellers because they describe what the module adds.
IntegrationBuilder gains with_middleware, which takes the page changes a module's registration supplies as SuppliedMiddleware values naming the middleware, the phase an entry names it in and the media type the entry covers. A middleware that runs in either phase is described in the one a generated configuration places it in. The registry refuses a registration whose middleware contradicts the description, in a phase it does not run in or for a media type it does not work on, and leaves a described middleware the registration does not supply alone, because a module may supply one only where its settings call for it. Core lists what a build supplies with supplied_middleware, in the order the registry registers them: what registers from the auction plan, then the built-in modules, then the linked builders in their order, then core's robots.txt and service version middleware, which no builder supplies. A tool that writes a configuration asks this of the builders it links and holds no table of its own. Every module in this repository that supplies middleware describes it, the script proxy and the seam probe included, and each proves under its own fixture settings that the description is exactly what it registers, through the helper in core's test support.
The ts tool lists the module builders it links in its own composition, in the order their request hooks run, and registers that list for deploy validation where it registered the stock crate's. The audit's generator writes the [[fetch]] and [[serve]] entries from what those builders describe of their middleware, through core's supplied_middleware, and finds the section a detected module is selected in and the name it is written under from the builder itself, so the command holds no table of modules. The tool depends on each module crate it links, and the list is public so the command's own integration tests register the same modules the command does.
crates/trusted-server-modules is removed. Each adapter lists the module builders it links in its own app.rs, as shipped_module_builders, in the order their request hooks run, which is the order the crate listed them, and composes a deployment's builders after them with module_builders_with. The adapters build their state and load their settings from that list where they took the crate's, and the Fastly adapter re-exports both so a deployment composing a binary of its own can take the list. The integration tests validate their fixture configurations against the Axum adapter's list. The tests the crate held move to where the thing they test now lives. Each adapter proves its own list's order and composition. The Axum adapter proves what the linked builders give a deployment, being the stock loading cache, each module's own deploy rules and secret settings, the diagnostics module's request preparer, the middleware the template and the guide document, the ad server's decision between planned bids and the maintainers every crate outside core names. The workspace, the cargo aliases, the guide, the onboarding page and the layout in AGENTS.md follow, with a design page for the change.
# Conflicts: # CHANGELOG.md # crates/trusted-server-modules/src/lib.rs
The Fastly adapter's tests call shipped_module_builders and module_builders_with and name IntegrationBuilder, so the test module imports them. The Axum shipped-modules test is formatted as cargo fmt wants.
…nd the rollout of the renames Review round 1 approved the design with no blocking issues and found gaps in what it covered. The design now names the four adapters, the integration tests crate and the three list functions with where each is exported, says what a deployment that keeps the stock set sees, and says that deploy validation never builds the registry, so a wrong description is refused only at startup and then stops the whole service. It gives the rollout of the renamed selectors, the renamed packages and the seam probe's names, what ts audit reads and writes, and the two things with no test. It defines iabtl and the stack, puts the renames in the title, and records the pull requests now raised and the review round.
Review round 2 found no blocking issues. The design no longer claims a test for ts audit leaving out a middleware described for another media type and lists that as a third untested item, records the three small changes left for a later change, and carries the round 2 entry in its review log and revision record. The changelog entries for the module list and the middleware list no longer say the removed crate holds them.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
The config push tests from the config by host change read a pushed document back with the stock module list from trusted-server-modules, which this branch removes. They now use trusted_server_cli::linked_builders, the list the ts command registers, as the audit diagnostics tests do.
… iabtl crate The configuration rules guide's table of old names to new had no row for the ads.txt module this branch renames from `ads-txt.sellers` to `ads-txt.iabtl`. The table now has that row, covering `[ads-txt] modules`, the module's table and the `[[fetch]]` entry that names its middleware. The table also holds the `[tinybird]` row that the branch making auction telemetry an analytics module adds, set in this branch's column widths, so that merging the branch below into this one resolves to this table. The APS guide's checks run the ad server's tests from `trusted-server-ad-server-iabtl`, the package this branch renames from `trusted-server-ad-server-mock`, and the APS crate's tests as the branches below run them.
Code scanning reported the test's assertion message as cleartext logging of sensitive information (alert 218), because the test read the module id from a builder that declares secret settings, and code scanning treats any value read from such a builder as a secret. The test now passes DATADOME_INTEGRATION_ID, as the 51Degrees middleware test passes its BUILDER_ID, so the message holds no value read from that builder.
jwrosewell
changed the title
jwrosewell
marked this pull request as ready for review
October 19, 2026 20:24
Each adapter's shipped_module_builders() and the tool's linked_builders() no longer carry trusted_server_loading_cache_51degrees::builder(), and the four adapters and the tool no longer depend on the module crate, so none of them compiles fiftyone-caching. the_stock_build_links_no_loading_cache sits beside each adapter's order test and fails if the list offers a loading cache, and the order tests stop naming loading-cache.51degrees. Nothing pinned the tool's list, so the tool gains the same guard and an order test of its own. The three tests in the Axum adapter's shipped_modules.rs that pinned the stock loading cache give way to the Axum adapter's guard, and the module crate's builder documentation says that no stock build links it.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Changes
crates/trusted-server-adapter-axum/testscrates/trusted-server-core/srccrates/trusted-server-cli/srccrates/trusted-server-adapter-fastly/srccrates/trusted-server-adapter-axum/srccrates/trusted-server-adapter-cloudflare/srccrates/trusted-server-adapter-spin/srcCargo.lockdocs/guidedocs/superpowerscrates/ad-tag/googlecrates/testing/iabtlcrates/ads-txt/iabtlcrates/bot-protection/datadomecrates/framework/nextjscrates/auction/prebidcrates/audience/permutivecrates/cmp/didomicrates/cmp/inmobicrates/cmp/sourcepointcrates/identity/lockrcrates/tag/google-tag-managercrates/tag/google-tagcrates/testing/testlightcrates/trusted-server-adapter-axum/Cargo.tomlcrates/trusted-server-adapter-cloudflare/Cargo.tomlcrates/trusted-server-adapter-fastly/Cargo.tomlcrates/trusted-server-adapter-spin/Cargo.tomlcrates/headers/geocrates/trusted-server-cli/Cargo.tomlAGENTS.mdcrates/trusted-server-cli/testscrates/trusted-server-integration-tests/srctrusted-server.example.toml.cargo/config.tomlCargo.tomlcrates/ad-server/iabtlcrates/trusted-server-adapter-cloudflare/testscrates/trusted-server-adapter-spin/testscrates/trusted-server-integration-tests/tests.github/workflowsCHANGELOG.mdcrates/trusted-server-integration-tests/Cargo.tomlTESTING.mdcrates/trusted-server-modules/Cargo.tomlcrates/trusted-server-modules/srcCloses
Closes #1334
Spec
Spec: no-modules-crate
Test plan
CI on this pull request at c60a832 passed all 20 checks.
cargo test-fastly && cargo test-axumcargo clippy-fastly && cargo clippy-axumcargo fmt --all -- --checkcd crates/trusted-server-js/lib && npx vitest runcd crates/trusted-server-js/lib && npm run formatcd docs && npm run formatcargo build --package trusted-server-adapter-fastly --release --target wasm32-wasip1fastly compute serveChecklist
unwrap()in production code (clippy deniesunwrap_usedin CI)logmacros as AGENTS.md asks (notprintln!)On top of the consent decoders series (#1383). Issue: #1334.
What changed after the 51Degrees PR review
Agreed at the review on 23 October, point 2. The 51Degrees loading cache is pluggable through modules, and the publisher asset feature becomes a module.
tstool links the loading cache module. Each adapter's list and the tool's list drop the 51Degrees loading cache module, so no stock build compiles it orfiftyone-caching, and a test beside each list fails if a module on it offers a loading cache.Agreed at the review on 23 October, point 4. Attestation leaves the stack, with no attestation interface in core.
testing.iabtl.Fixes found in review
tslist, where it said the list had none.ts config validaterefusing a loading cache module it does not link. It takes the place of the test that went with the stock lists' loading cache.Kept current
mainat 7aa5c99, the changes made lower in the stack andfiftyone-caching4.5.13 (Move the loading cache module to the released caching crate #1372).What this adds
What changes.
crates/trusted-server-modulesis gone. Each adapter lists the modules it links in its ownapp.rs, each module describes the middleware it supplies, thetscommand asks the builders it links, and the three modules this repository ships under names that said nothing about their maintainer are named for it:crates/ad-server/iabtl,crates/testing/iabtlandcrates/ads-txt/iabtl.How it works.
shipped_module_builders()in each adapter'sapp.rsis the same twenty builders in the same order the crate listed them, andmodule_builders_with(extra)puts a deployment's own after them. None of them offers a loading cache, so no stock build links the loading cache module, and a deployment that wants copies kept hands a loading cache module's builder to its adapter with its own. The integration test crate takes the Axum adapter's list, because its fixtures are validated against what the adapters have.IntegrationBuilder::with_middlewaretakes the middleware a module supplies with their phases and media types,supplied_middleware(builders)gives them in the registry's order with core's own rows (the script proxy, robots.txt, the service version), and the registry refuses a registration whose description contradicts what it registers. A description is optional, because the registry's own tests register middleware in many places and a registration can be conditional, and each stock module proves its description against its registration in a test of its own.tscommand asks the builders. The audit's entries come fromsupplied_middlewareover the builders the command links, and a module's selection comes from the builder's own section and name, so the command holds no table.[ad-server] module = "iabtl"with[ad-server.iabtl],[ads-txt] modules = ["iabtl"], and the seam probe's[shared.iabtl],loading-cache.iabtlandiabtl-answerscache follow the folders. Type names, log labels, the probe's integration id, routes and page markers stay, because they say what the thing does rather than where it lives.Why
Nothing is shared by being listed. Every piece of functionality is its own crate under
crates/<type>/<vendor>/, withiabtlas the vendor where this repository's own initial version has no vendor, and each adapter and each deployment names the crates it links itself. A module that describes its own middleware is the only place that description cannot drift from the code.What breaks
A deployment that selected
mockorsellerswritesiabtl, and one whose settings named the seam probe's shared table or cache follows the rename, each listed with its old and new form in the changelog. A crate outside core that depended ontrusted-server-modulesnames the crates it links instead.The commits
cargo fmtwants.tscommand links, in place of the removed modules crate's list.tscommand links the loading cache module or depends on its crate, so a stock build compiles neither the module norfiftyone-caching, and a test beside each list fails if a module on it offers a loading cache.iabtl.