otel_contract: one declarative contract file consumed by the rails' export tests, and one source for the probed-service list

[aaylward]

Two single-sourcing follow-ups from the #1304/#1305/#1307 review panel. Both are the same shape: a contract that lives in N hand-maintained copies that nothing ties together.

1. A declarative contract file the rails' export tests consume

All three rails now pin the http_server_* contract behaviorally, against real exported payloads: server_pal's http_metrics_label_tests (in-memory exporter), futility's http_metrics_test + http_instrument_descriptions_test (capturing recorder / in-memory reader), and yodel's OtlpJsonEncoderTest (the actual OTLP JSON). Cross-rail equality currently holds because each rail's test states the same expectations in its own language, plus otel_contract's text pins for the named constants (descriptions, bucket bounds, route literals).

The end state the panel pointed at: otel_contract/http_contract.json (or textproto) declaring the five instrument names, descriptions, routed and gauge label sets, bucket bounds, and unit "" — loaded by each rail's existing export test as a data dep (Java resource, cc_test data, Rust compile_data + include_str!) and asserted against the real payload. Cross-rail equality then holds by construction, and the remaining source-regex pins (descriptions, buckets) can be deleted the way the label/unit regexes were in the #1304/#1305 PR: a regex over source can agree with the code while disagreeing with the wire, which is the failure mode the contract package exists to prevent.

2. One source for "which services carry steady probes"

serviceOrder in domains/platform/apis/prom_proxy/registry.go and servicesWithSteadyProbes in deploy/consolidated/deploy_config_test.go are the same seven names in two Go modules with no link. TestEveryProbedServiceKeepsItsProbesTile forces a Probes tile on every registry entry on the stated assumption that "deploy's config test pins that side" — but the deploy test iterates its own literal list. Adding an eighth service to the registry mandates a tile and mandates nothing about compose: the tile ships reading a permanent zero, which both files independently name as "a zero that means healthy and also broken."

A shared data file (could be the same contract file as above, or its own) or a Probed bool on serviceEntry with the deploy test reading the registry would close it.

[aaylward]

One more item for the declarative-contract work, from #1309's review: futility's label-set pins stop one seam short of the wire. CapturingMetricsRecorder snapshots attributes before forwarding into MetricsRecorder::Record*, so http_metrics_test pins what HttpMetricsManager passes to the recorder — an attribute drop inside RecordWithAttributes would still pass it. Descriptions and units on this rail are already export-tested (http_instrument_descriptions_test reads descriptors off a real in-memory export); when the rails' export tests grow the contract-file assertions, the C++ one should assert label sets at that same level, closing the gap. Rust and Java already pin labels at the wire.

---

Generated by Claude Code

[aaylward]

#1450 adds a third hand-kept copy of a per-service metric contract, which is more evidence for this issue's shape: HubHandler::DeclaredCounterSeries() (C++) is the emitter's roster, hub_e2e_test carries a literal copy, and prom_proxy's registry_test.go now holds golfHubExportedNames / microgptExportedNames plus label vocabularies (result/resumed/endpoint) — hand-verified against the emitters, with nothing cross-language to pin them.

A cheap same-repo step short of the full contract: DeclaredCounterSeries() is already machine-readable, so a checked-in roster file consumed as a Bazel data dep by both the C++ declaration test and the Go audits would make the Go copies underivable-from-drift. Custom per-service instruments, not just the http_server_* family, now look like they belong in this issue's scope.

---

Generated by Claude Code