Merged
Conversation
Member
Author
|
To remove the Since the only have index-based envelope item access happens inside our unit tests, there is no real performance impact. This allows for attachment counts limited only by available memory. |
Member
Author
|
@sentry review |
Contributor
|
Can we add a test that allocates more than 10 items in an envelope, and utilizes the functions we changed. Also, we could think about performance implications, since now we need to loop through all of the items in the linked list to find the correct one on the proper index. But two questions:
|
- reason: span tags are a legacy concept so we're not touching it ~dixit ingest
06333dd to
bdebd99
Compare
- no longer limited to 10; we test for 15, but have tested up to 1000 transactions locally and that works
mujacica
approved these changes
Dec 1, 2025
Contributor
mujacica
left a comment
There was a problem hiding this comment.
Thanks for adding the test.
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 #1342
Truncation occurrences
MAX_ENVELOPE_ITEMSSee definition https://github.com/getsentry/sentry-native/blob/master/src/sentry_envelope.h#L13
This is only used in
envelope_add_item(here) which can only trigger for attachments (since the other APIs callingadd_itemall capture the envelope after adding the first item), so if a user sets more than 9 attachments we would lose the 10th onward.The Envelopes docs mention that we accept as most 100 sessions per envelope, which is presumably where this
MAX_ENVELOPE_ITEMSoriginated from. The question now is whether this also applies to other envelope items (like attachments/events/...)?-> we should only have the limit for sessions, not attachments (or other envelope items). we should check whether we can actually construct envelopes with multiple sessions, and if so, still limit this to 100 (not 10). Remove 'truncating'(dropping) envelope items for any other type of telemetry. ( ✅ updated session test )
Out-of-Scope
Stack Traces
It was decided that Stack Trace Truncation was out of scope for this first round of SDK truncation logic updates (TODO: link new Linear ticket for this topic)
🔍
sentry_unwind_stack(..., max_frames)Code here. Need to investigate if this is something we should be truncating still, or if Relay can handle this.
🔍 inproc
MAX_FRAMESCode here and used for unwinding the stack here
Keep non-truncated
✅
sentry_set_tagCorrectly gets truncated to 200 characters in Relay (count including ...)

Keep truncation
Span Tags
We keep truncation because
The following was observed with this snippet:
Code Snippet
```c sentry_transaction_context_t *tx_ctx = sentry_transaction_context_new("my_tx", "op"); sentry_transaction_t *tx = sentry_transaction_start(tx_ctx, sentry_value_new_null()); sentry_span_t *span = sentry_transaction_start_child(tx, "span_op", "span_desc"); char *tag = "supermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagname"; char *tag_val = "supermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagnamesupermegalongtagname"; sentry_set_tag(tag, tag_val); sentry_span_set_tag(span, tag, tag_val); sentry_span_finish(span); sentry_transaction_finish(tx); sentry_value_t event = sentry_value_new_message_event( SENTRY_LEVEL_INFO, "my-logger", "Hello World!"); ```❓
sentry_span_set_tag(from a prior discussion, TBD if this is still true)
(UPDATE 2025-11-13) -> we see correct truncation on transactions, but not on spans yet
code here and mention of truncation for
sentry_span_set_taghereremoved in a9712b2 but seems like this is not truncated during ingestion... docs mention that tags must be less than 200 characters

Product doesn't seem to like these large values for searchability
