mirror of
https://github.com/XRPLF/rippled.git
synced 2026-09-27 15:28:03 +00:00
2097293e8f
The two log.trace_id_* checks have failed on every run -- they were the only failures in the 2026-08-20 run (158/160). The workload never satisfied their precondition, because warning suppressed the one line that is correlated by construction. trace_id is injected in Log.cpp from RuntimeContext::GetCurrent(). Severity does not affect injection, but JLOG filters on severity before format() runs, so what matters is which severity emits a line while a span is current. A span becomes current in either of two ways: as a ScopedSpanGuard, or by activating a plain SpanGuard via activate() / activateIfLive(). activate() returns a ScopedActivation holding an otel_trace::Scope built from the span, which pushes onto the same RuntimeContext store Log.cpp reads. A plain SpanGuard that is never activated makes no span current. The guaranteed correlated line at info is the consensus accept pair at RCLConsensus.cpp:736/740 -- an if/else, so exactly one fires on every accepted round. doAccept activates the accept span as ambient over its whole body at :565 via activateIfLive(acceptSpan), and that activation lives to the end of the function, so both branches are inside it. At roughly one round every 4 s this gives dozens of correlated lines per run, well inside the validator's 4 h window. LOG_QUERY_WINDOW_SECONDS stays at 4 h deliberately -- a wider window would let the check pass on logs from a previous run. info is the minimum that works, which is what the task asked for. debug would correlate strictly more, additionally covering BuildLedger.cpp:81 and RPCHandler.cpp:188, but it is the wrong default: it puts synchronous log I/O inside ledger.build, consensus.accept (RCLConsensus.cpp:663 logs per transaction) and tx.apply, which are exactly the spans whose latency regression-metrics.json gates. The next run reprints the voided baseline, so capturing at debug would bake log I/O into the latency numbers permanently -- the same class of defect this plan exists to remove. The runbook records how to get the broader coverage per partition, after a baseline exists.