[mnoah1]

Why

The reusable SubmitQueue and Stovepipe UI packages currently depend on OpenTelemetry and accept OTel meters and tracers. That couples both metrics and tracing to one telemetry stack.

A host using native M3 counters and histograms should not need an adapter to OTel's Meter API just to reuse the UI. The same applies to a host with another tracing stack. Let each host use its native metrics and tracing APIs without forcing either a meter adapter or a tracer bridge.

How it works

The reusable packages keep routing, authorization decisions, queue and request loading, page models, React UI, and request-scoped logging. They no longer import OTel or accept tracing and metrics options.

Hosts instrument the boundaries they own:

• Wrap the normal web.handle() call to record page-load metrics, outcomes, and spans.
• Instrument their concrete RPC client for backend-call metrics, tracing, and trace-context propagation.
• Configure their own providers and exporters.

The reference hosts use native OTel APIs. An M3-backed host can emit the same measurements through native counters and histograms; no OTel-to-M3 bridge is required. Stovepipe's page-load measurements are:

• stovepipe.web.page_loads: a counter tagged by outcome.
• stovepipe.web.page_load_duration: a duration histogram in milliseconds, tagged by outcome.

Metric names and units are retained, while bucket configuration, providers, and exporters belong to the host. There is no replacement meter or tracer interface and no generic instrumentation callback in the reusable packages.

For Stovepipe, handled section failures get outcome=error even when the library returns a rendered page; unexpected exceptions get outcome=exception. Metric or trace delivery failures do not repeat reads or replace their results or errors.

Tradeoff

Host-boundary instrumentation measures whole page loads and injected calls, not arbitrary private-library steps. A host can wrap an injected dependency to add metrics or spans around an operation the library calls. Per-step counters, histograms, or spans entirely inside the library would require a separate, explicit instrumentation decision.

No route, UI, backend IDL, or browser API changes are included.

Test plan

• ./tool/bazel test //web:check --test_output=errors: all 30 targets pass, including package-boundary and React 18 compatibility checks.
• Tests cover handled section failures, telemetry failures, preserved results and errors, isolated request contexts, and RPC duration metrics.
• make fmt lint check-tidy check-gazelle and git diff --check pass.