chore: Refactor SentryAttributes into a separate class#4936
chore: Refactor SentryAttributes into a separate class#4936jamescrosswell wants to merge 10 commits into
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.25% +0.16%
==========================================
Files 506 508 +2
Lines 18247 18282 +35
Branches 3564 3574 +10
==========================================
+ Hits 13519 13575 +56
+ Misses 3858 3835 -23
- Partials 870 872 +2 ☔ 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.
| } | ||
|
|
||
| writer.WriteEndObject(); | ||
| Attributes.WriteTo(writer, logger); |
There was a problem hiding this comment.
suggestion: revert
see also https://github.com/getsentry/sentry-dotnet/pull/4936/changes#r3217641003
As this abstraction of SentryAttributes is only used in SentryMetric, but not in SentryLog, I personally find this abstraction a bit "hasty".
There was a problem hiding this comment.
It was originally used in these places as well:
So it seemed like a logical refactoring... This whole refactoring would be premature if we hadn't already tried to use it in #4912.
We can revert this if you really want, but I'm pretty sure we're just going to bring it back in again as soon as we build the next thing that has attributes. I think it just makes the code a bit more readable - one descriptively named method call instead of 9 lines of code (whose purpose you have to reverse engineer).
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>
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