fix(core): Serialize streamed span status message to sentry.status.message attribute#21811
Open
Lms24 wants to merge 3 commits into
Open
fix(core): Serialize streamed span status message to sentry.status.message attribute#21811Lms24 wants to merge 3 commits into
sentry.status.message attribute#21811Lms24 wants to merge 3 commits into
Conversation
sentry.status.message attributesentry.status.message attribute
…essage` attribute
fbab8c3 to
c18bd3e
Compare
Contributor
size-limit report 📦
|
sentry.status.message attributesentry.status.message attribute
Comment on lines
+355
to
+359
| const statusMessage = getSimpleStatus(status) === 'error' ? status?.message : undefined; | ||
| return { | ||
| ...(statusMessage && { [SEMANTIC_ATTRIBUTE_SENTRY_STATUS_MESSAGE]: statusMessage }), | ||
| ...attributes, | ||
| }; |
Contributor
There was a problem hiding this comment.
Bug: The addStatusMessageAttribute function always creates a new object, which contradicts its documentation comment stating the original reference would be returned.
Severity: LOW
Suggested Fix
Modify addStatusMessageAttribute to check if a statusMessage exists. If it does not, return the original attributes object directly. Otherwise, proceed with creating and returning a new object with the added attribute.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/core/src/utils/spanUtils.ts#L355-L359
Potential issue: The function `addStatusMessageAttribute` in `spanUtils.ts` has a
comment stating that it will return the original `attributes` object reference untouched
if no status message is added. However, the implementation always creates a new object
via spread syntax (`{ ...attributes }`), even when no message is present. While this
does not cause a functional bug as no downstream code relies on reference equality, it
creates a minor inefficiency by allocating a new object unnecessarily and makes the
code's behavior inconsistent with its documentation.
Did we get this right? 👍 / 👎 to inform future reviews.
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 a semi-deliberate oversight (lol) from my end that caused span status messages to be discarded when creating a
StreamedSpanJSONfrom aSpaninstance. The deliberate part was to get rid of complicated statuses overall. The oversight was that there's a good use case to augment anerrorstatus span with a message: We sometimes want to record that an operation tracked by a span errored but explicitly not capture an error for it (since users likely try/catch said operation). Classic example isConnection Refusedfor databases.closes #21800