Merge branch 'pratik/otel-phase5-docs-deployment' into pratik/otel-phase6-statsd

This commit is contained in:
Pratik Mankawde
2026-08-14 21:18:05 +01:00
5 changed files with 14 additions and 17 deletions

View File

@@ -95,9 +95,8 @@ message TMPublicKey {
// Older peers that do not understand field 1001 will simply ignore it
// per protobuf wire-format rules, preserving backwards compatibility.
//
// trace_state is reserved for future use (secure tracing pipeline,
// OpenTelemetryPlan/secure-OTel.md). It is currently neither populated
// on inject nor read on extract; consumers must not rely on it.
// trace_state is reserved for future use. It is currently neither
// populated on inject nor read on extract; consumers must not rely on it.
message TraceContext {
optional bytes trace_id = 1; // 16-byte trace identifier
optional bytes span_id = 2; // 8-byte parent span identifier

View File

@@ -101,13 +101,10 @@ injectToProtobuf(opentelemetry::context::Context const& ctx, protocol::TraceCont
// Serialize flags
proto.set_trace_flags(spanCtx.trace_flags().flags());
// TODO(observability/secure-OTel): the protobuf TraceContext message
// also carries `trace_state` (field 4), which is currently neither
// populated here nor read by extractFromProtobuf above. The field is
// reserved for the secure tracing pipeline outlined in
// OpenTelemetryPlan/secure-OTel.md, where an authenticated token in
// tracestate will let receivers reject spoofed/poisoned trace context.
// Wire trace_state through inject/extract once the consumer lands.
// TODO: the protobuf TraceContext message also carries `trace_state`
// (field 4), which is currently neither populated here nor read by
// extractFromProtobuf above. The field is reserved for future use;
// wire it through inject/extract once a consumer lands.
}
} // namespace xrpl::telemetry

View File

@@ -274,9 +274,9 @@ RCLConsensus::Adaptor::propose(RCLCxPeerPos::Proposal const& proposal)
app_.getHashRouter().addSuppression(suppression);
// Inject the current thread's active span context (e.g. the
// consensus round span from Phase 4) so receiving peers can link
// their proposal.receive span as a child of this trace.
// Inject the current thread's active span context (e.g. the consensus
// round span) so receiving peers can link their proposal.receive span
// as a child of this trace.
telemetry::SpanGuard::injectCurrentContextToProtobuf(*prop.mutable_trace_context());
app_.getOverlay().broadcast(prop);

View File

@@ -127,9 +127,9 @@ class RCLConsensus
*
* Captured in makeAcceptSpan() and consumed by createValidationSpan()
* on the jtACCEPT worker thread so the validation.send span can be
* follows-from linked to consensus.accept (matching the design doc
* and span hierarchy diagram). Reset on each startRoundTracing()
* to prevent a stale prior-round context from being linked.
* follows-from linked to consensus.accept. Reset on each
* startRoundTracing() to prevent a stale prior-round context from
* being linked.
*
* Thread safety: same model as roundSpanContext_. The write in
* makeAcceptSpan happens on the main consensus thread under

View File

@@ -34,7 +34,8 @@
*
* @note Span names come from the canonical constants in
* ConsensusSpanNames.h (consensus::span::proposalReceive /
* validationReceive) so they stay in sync with the rest of Phase 4.
* validationReceive) so they stay in sync with the rest of the
* consensus tracing surface.
*/
#include <xrpl/consensus/ConsensusSpanNames.h>