Auction telemetry is switched on by a flag inside its vendor's table, where every other job selects its module by name #1274

The problem

After the seam (#1094) a vendor's module is selected by name. A section named for the job says which module does it, and the module's settings sit in a table at its name. Auction telemetry does not follow that. Its section is named after its vendor, [tinybird], and a flag inside the vendor's own table switches it on, so a second place to send auction events would need a second section and a second flag.

The change

[analytics]
module = "tinybird"

[analytics.tinybird]
api_host = "api.example.com"
auction_token_secret = "tinybird_auction_append_token"

Settings::telemetry() returns the module's settings only when the section selects it, so the Fastly sink has no enabled flag of its own, and settings that select nothing build the sink that sends nothing. module takes the short name or the full one, as every selector does. The secret reference moves to analytics.tinybird.auction_token_secret, and the references of a table nothing selects are cleared before secrets are resolved, so what an operator sees is a refusal and not a failed secret lookup.

[analytics] with no module, a module this build does not have, a key the table does not know (enabled included) and the old [tinybird] table are each refused when the settings load, the last with directions. An earlier version wrote [tinybird] into every stored configuration whether telemetry was on or off, so a stored configuration is pushed again with this version's ts config push, which the removal of administration already needs. The Tinybird code itself stays where it is, and moving it into a crate of its own is a change of its own.

Where it is

Draft on the fork, jwrosewell#11, on top of the diagnostic headers change (fork pull request 10).