Expand description
Wall-clock timing for the named stages a run is made of.
A sync loop iteration, a sync cycle, a Store pull, and a database open are each a sequence of named stages — probe the provider, drain uploads, discover streams, verify commits, migrate, install a snapshot image, materialize. When one of them takes twenty seconds the only useful question is which of those stages it spent them in, and the logs have to answer it without a second round of instrumentation.
This lives in the foundation rather than beside the sync loop because the slow stages are not all in one crate: a device join spends most of its time inside a database open, and timing that from the caller only ever reports one opaque total.
Each run holds one StageTimings, times every stage through it, and
reports one line naming each stage’s total. Stages repeat — a pull discovers
once per device stream and applies once per commit — so a stage’s entry
accumulates across the run instead of being replaced, and only stages that
actually ran appear (a stage skipped because a key rotation is pending is
absent, not zero). Nested runs report their own line, so the cycle’s pull
stage and the pull’s own line describe the same span at two levels of detail.
The reported total is the run’s whole wall time, so time spent outside every
named stage stays visible as the difference rather than disappearing.
Timing reads a Stopwatch, not the injected
Clock: this measures how long real work
took, not what the store stamps its commits with.
A time alone does not say what a stage waited on, so a run whose storage can
count what it asks of the provider is started with
StageTimings::counting and reports each stage’s operation count beside
its time. That is the form the round-trip budget is written in: a join is
one snapshot download and a handful of small operations, and a stage that
exceeds that says so in its own line.
Structs§
Traits§
- Provider
Requests - The running total of provider operations the storage behind a run has issued.