chore: Refactor SentryAttributes into a separate class#4936
Conversation
Semver Impact of This PR⚪ None (no version bump detected) 📋 Changelog PreviewThis is how your changes will appear in the changelog. This PR will not appear in the changelog. 🤖 This preview updates automatically when you update the PR. |
jamescrosswell
changed the title
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4936 +/- ##
==========================================
+ Coverage 74.08% 74.12% +0.03%
==========================================
Files 506 508 +2
Lines 18247 18282 +35
Branches 3564 3574 +10
==========================================
+ Hits 13519 13551 +32
- Misses 3858 3861 +3
Partials 870 870 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
@Flash0ver is there any reason not to approve/merge this PR? The changes are internal only (so we can easily refactor again later if we need) and all the tests pass. Can we not just get this out of the way so we can move on to other stuff? It's been waiting for a review for over 2 months now. |
There was a problem hiding this comment.
No reason ... I was just slow ... getting all the reviews done now.
I love the refactoring ❤️.
This removes duplicate code, and gives even more control to testing.
I got a couple of suggestions to make the implementation and usage aligned across SentryMetric and SentryLog.
Replace the private `_attributes` field with an `internal SentryAttributes Attributes { get; }` property after `SpanId`, matching the `SentryMetric` pattern. Remove the internal typed overloads (`TryGetAttribute<string>`, `SetAttribute(string/char/int)`) and update all callers to go through `log.Attributes` directly. Update tests to use `ShouldContain`/`ShouldNotContain` extension methods.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…utes Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit c48cbd8. Configure here.
Change ShouldNotContain<string> to ShouldNotContain<object> to match
previous semantics, and replace Attributes.SetAttribute("null", null!)
with the public metric.SetAttribute<object>("null", null!) overload.
Remove the now-unreachable null warning expectation.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Remove the early null-return from SentryAttributes.SetAttribute so null values are stored in the collection and the existing null warning in SentryAttributeSerializer fires consistently during serialization for both SentryLog and SentryMetric. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- SentryAttributes.TryGetAttribute: "this" → "this attribute collection" - SentryAttributes.SetAttribute: rephrase summary doc - SentryAttributes.SetAttribute<T>: remove unnecessary null-suppression operator - SentryAttributes.TryGetAttribute: update seealso href to attributes docs - SentryLogTests: use ShouldContain/ShouldNotContain instead of TryGetAttribute - SentryLogTests: remove unnecessary null-forgiving operators Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2 participants
Before closing #4912 I figured we could extract some of the refactorings that might be useful in other PRs dealing with Attributes. Basically there's some functionality that is only accessible in the
SentryMetricsclass at the moment, but which will be needed by any other classes that also have Attributes.#skip-changelog