Conversation
Set() always appended a new entry, even when the key already existed,
rather than overwriting it in place as required by the W3C trace-context
spec ("only one entry per key is allowed"). Repeated Set() calls on the
same key duplicated the entry every time, filling kMaxKeyValuePairs with
stale copies of one key and silently dropping any later, genuinely new
key once the limit was reached.
Now checks whether the key already exists before allocating: an update
never grows the list, and the stale entry for that key is skipped when
copying the rest over, so the list only ever holds one entry per key.
Fixes open-telemetry#4583
Member
Contributor
Author
|
You're right, my mistake for overlooking. I didn't check for a linked PR before starting. Closing this in favor of #4586. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4610 +/- ##
==========================================
+ Coverage 86.51% 86.52% +0.02%
==========================================
Files 525 525
Lines 20464 20468 +4
==========================================
+ Hits 17702 17708 +6
+ Misses 2762 2760 -2
🚀 New features to boost your workflow:
|
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
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.
Fixes #4583
Changes
TraceState::Set()always allocated room for and appended a new entry, even when the given key already existed in the list. Per the W3C trace-context spec, "only one entry per key is allowed", and vendors must overwrite their entry on reentry, butSet()never checked for an existing entry before appending, so calling it repeatedly with the same key just kept adding duplicates.Two visible effects, both matching the issue:
ToHeader()emits the same key more than once, which is not a valid trace-context header.kMaxKeyValuePairsis reached and any later, genuinely new key gets silently dropped, even though the list logically has room.The fix checks whether the key already exists first: an update reuses the existing slot (list size does not grow), and the stale entry for that key is skipped when copying the remaining entries over, so the list only ever holds one entry per key. The already-documented "list full" behavior for a real new key is unchanged.
Added
TraceStateTest.TraceStateSetOverwritesExistingKey, which sets the same key many times pastkMaxKeyValuePairsand checks both that the value is updated and that a subsequent distinct key can still be added afterward. Confirmed it fails against the pre-fix code (it fills up with 30 duplicate entries and the new key gets dropped) and passes after the fix.CHANGELOG.mdupdated for non-trivial changes