docs(rfc-0002): correct span.kind wire format in code sketches - #4316
Closed
DsThakurRawat wants to merge 1 commit into
Closed
docs(rfc-0002): correct span.kind wire format in code sketches#4316DsThakurRawat wants to merge 1 commit into
DsThakurRawat wants to merge 1 commit into
Conversation
The OtelSpan interface comment and the parseOtlpTrace sketch both state
that span.kind arrives as the protojson enum name "SPAN_KIND_SERVER" and
that the parser should strip the prefix.
The "Field encodings on this route" table fifteen lines below the sketch
says the opposite, and the paragraph after it already notes that the
sketch's comment assumed wrongly. Both readings remain in the document,
and the incorrect one sits inside the function body a contributor would
copy when implementing Milestone 3.2.
Verified against jaegertracing/jaeger:latest (v2.20.0, git-commit
d65f9516): GET /api/v3/traces/{trace_id} returns "kind": 2 as a bare
JSON number, and the field is absent when the value is UNSPECIFIED. The
checked-in fixture packages/jaeger-ui/src/utils/fixtures/otlp2jaeger-in.json
also carries kind as a number.
Documentation only; no code paths affected.
Signed-off-by: Divyansh Rawat <divyanshrawatofficial@gmail.com>
Author
|
Closing this RFC-0002's code sketches are the subject matter of the LFX #2029 project itself, and I'd rather not pre-empt that discussion. Happy to revisit once the project starts |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which problem is this PR solving?
#4275 added the Field encodings on this route table to RFC 0002 and noted that
span.kindarrives as a JSON number, explicitly flagging that "the sketch's comment above assumed" the
protojson enum name. The table landed, but the two code sketches it refers to were left unchanged.
So the document still says both things. The
OtelSpaninterface comment and theparseOtlpTracesketch under Milestone 3.2 tell the reader that kind arrives as
"SPAN_KIND_SERVER"and that theSPAN_KIND_prefix should be stripped, while the table fifteen lines below the sketch says it is aJSON number omitted at zero.
The stale wording is the copy sitting inside the function body someone would start from when
implementing 3.2.
Description of the changes
Update both sketches to match the encoding table, and point the reader at it.
How was this change tested?
Verified against
jaegertracing/jaeger:latest(v2.20.0, git-commitd65f9516):kindis a bare JSON number, and a span posted over OTLP withkind: 0comes back with the fieldabsent. The checked-in fixture
packages/jaeger-ui/src/utils/fixtures/otlp2jaeger-in.jsonalsocarries
kindas a number.Documentation only; no code paths affected.
Checklist