Repository navigation
Add a table that a vendor's modules share - #1367
Open
jwrosewell wants to merge 43 commits into
Open
jwrosewell wants to merge 43 commits into
jwrosewell wants to merge 43 commits into
Conversation
`[shared.<vendor>]` holds what every module of one vendor reads, such as an endpoint and a license key, so the key is written once. Core declares the tables and reads none of them. A vendor's crates read their own as typed settings through `Settings::shared_config`, which refuses a table that cannot be read as the type or fails its validation, naming the table. A table whose name is not a folder name is refused when the settings load. A builder marked with `with_shared_settings` is run by its vendor's table rather than by a selection, so a document without the table runs none of that vendor's modules, and a selection naming one of them is refused with the absent table named. A table that no builder reads is refused when the registry is built, the one place every builder is known. A secret in the table is declared with the builder's secret settings at its path inside the table and resolved when the table is present, as a module's own secrets are. The seam probe gains a second builder its table runs, whose route answers the table's marker, so the Axum adapter proves the table from outside core.
The configuration guide lists `[shared]` among the sections and describes the tables, what runs a builder, the refusals and how a secret in a table is written. The integration guide's builder table gains `.with_shared_settings(...)` and a section on reading the table as typed settings. The example configuration notes the table beside its list of sections, and the changelog records the addition.
…tables # Conflicts: # CHANGELOG.md # crates/trusted-server-adapter-axum/tests/seam_probe.rs
The registry refuses a builder marked with with_shared_settings that also has a module name, since a section could otherwise select what the table runs. A refusal of a list selection now names the absent shared table, as the single selector refusal does. Two misplaced doc comments are back on their items, and no comment or guide names a crates/shared folder.
This was referenced Oct 15, 2026
By the time a vendor reads and validates its shared table at startup, the table holds each of its secrets resolved from the secret store. A table that could not be read or failed its validation was refused with the underlying error, which can quote the value at fault. The serde crate quotes a string it cannot read as the type asked for, and the validator crate prints each failed rule's parameters, the checked value among them. Each adapter logs the whole failure when its state fails to build. The refusal now names the table and the setting at fault and never the setting's value. A read error gives the path of the setting, found with serde_path_to_error, which edgezero-core already depends on, and keeps serde's own message only when it names keys alone, being a key missing, unknown or written twice. A validation error goes through validation_error_summary, as core's own settings do, which names the field, the rule and the rule's own message.
A module's own table holds the module's secrets resolved from the store at startup in the same way, and module_config refused it with the underlying error in the same way. It now reads the table through the same function as a shared table, so its refusals name the setting at fault and never its value.
The push check that each secret setting in use names a key found a builder's secrets through its module name and the section selecting it. A builder its vendor's shared table runs has neither, so a secret setting in a shared table was never checked, although the configuration rules say every secret setting is. The check now reads such a builder's secrets from its vendor's table when the table is present, with the rule the loader applies for whether the table uses a setting, and names the setting as shared.<vendor>.<path>.
From this branch a refused module table names the setting at fault and never its value, so loading settings with an out of range cmp_id says that cmp_id in [cmp.inmobi] holds a value of the wrong type or form, and no longer the range message the module's reader gives, which quotes the value. The InMobi test of the CMP id range checks each of its six values for the table and the setting, and that the value is not quoted.
This was referenced Oct 17, 2026
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-core/srccrates/testing/seam-probecrates/trusted-server-adapter-axum/testsdocs/guidetrusted-server.example.tomlCHANGELOG.mdCloses
Closes #1284
Spec
Spec: shared-vendor-tables
Test plan
CI on this pull request at 180c491 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!)Stacks on robots.txt as a middleware (#1366).
Kept current. This update only merges the pull request below (#1366), which brings Tech Lab's
mainat 7aa5c99 and the changes made lower in the stack.What this pull request does
One
[shared.<vendor>]table per vendor, holding what every module of that vendor reads. Core declares the tables and reads none of them. A vendor's crates read their own as typed settings withSettings::shared_config::<T>(vendor), which refuses a table that cannot be read asTor fails its validation, naming the table and the setting at fault and never the setting's value.A builder marked with
IntegrationBuilder::with_shared_settings(vendor)is run by the table rather than by a selection, and so takes no module name. Settings without the table run none of that vendor's modules, a selection naming one of them is refused with the absent table named, and a builder the table runs is selected by no section. A table that no builder reads is refused when the registry is built, the one place every builder is known, and a table whose name is not lower case letters, digits,_or-is refused when the settings load.Core does not refuse a key written both in a module's own table and in the shared table. Which one wins is the vendor crate's choice.
A secret in the table is declared with the builder's secret settings at its path inside the table, as a module's own secrets are declared in its own table, resolved from the secret store when the table is present.
The seam probe gains a second builder,
shared_builder, which[shared.seam-probe]runs and whose route answers the table's marker. The Axum adapter's test serves the route with the table, finds it absent without, and is refused at startup for the table with no builder reading it.Why
A vendor with several modules, a device module, a geo module and an identifier module, say, has one service they all call and one key for it. Without this the key is written once in each module's table, and a module cannot be built on what another module's table says. The table is also what runs the vendor's builder, so the deployment runs the vendor's modules together or not at all.
How it was verified
Not exercised. No vendor crate reads a shared table in the stock build. The probe's builder is the one reader, through the Axum adapter.
References #1284.