Module invocation_metrics 

Per-invocation metrics for plugin execution.

Each call into a plugin emits an InvocationMetric on a broadcast channel (InvocationMetricsBus). Observers — the admin UI’s plugin status page, an OTLP exporter for cloud metering, a billing aggregator — subscribe and consume.

This is the foundation for cloud-plugins Phase 2 metering: the bus shape is the same whether we’re emitting locally for the OSS admin UI or shipping events to a SaaS billing pipeline. Local first, cloud second.

Why a broadcast channel

Multiple subscribers each get every event without coordinating. Slow consumers don’t slow down the producer — tokio::sync::broadcast drops messages for laggers and surfaces it as a RecvError::Lagged, which is the right semantics for telemetry (better to miss a sample than to backpressure the request path).

Why RAII for the timer

The producer side is wrapped in InvocationTimer, which records the start instant on construction and emits the metric on finish_*. Forgetting to finish a timer is a (warned) bug; the Drop impl emits a “dropped” metric so we don’t silently lose calls.

Structs

InvocationMetric

One plugin invocation’s measured cost + outcome.

InvocationMetricsBus

Broadcast bus that fans an InvocationMetric out to subscribers.

InvocationTimer

RAII guard that times a plugin invocation and emits one InvocationMetric when finished.

Enums

InvocationStatus

Outcome of a plugin invocation, attached to each InvocationMetric.