-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(event-schema): Copy root span data when converting from events #3790
Conversation
@phacops or @jjbayer, I'd ask for input on how to proceed. I'm not sure on the reasoning behind making the two data types separate, nor whether roundtrip behavior is actually needed anywhere. We do have a test for this, but from what I can see in the code base we never actually require proper roundtrips. |
I'm in favor of merging We can break up the roundtrip test. We convert transactions to spans and have a feature that converts standalone spans to transactions (which we will hopefully remove soon), but one and the same data item is never roundtripped in real life. |
Thanks, @cleptric also confirmed that we can merge these types.
Can you point me to that? For this feature, do we need to remove some attributes that are currently not cloned over, such as the |
relay/relay-server/src/services/processor/span/processing.rs Lines 115 to 116 in 173a8da
No I think it's fine if we fully copy |
* master: feat(getter): Add logentry getter to event (#3796) feat(rule-condition): Add `any` and `all` loop conditions (#3791) ref(normalization): Remove normalization debug metrics (#3786) fix(redis): Fix Redis data corruption on connection timeout (#3792) fix(spans): Fixes span outcomes and inherited rate limits (#3793) build(py): Update craft to use new manylinux wheels (#3789)
…3790) SDKs place span data for root spans into `event.contexts.trace.data`. Therefore, top-level span data was missing for metric extraction and in indexed spans. This PR copies trace data over to the root span when events are converted to spans. The two types used for trace data and span data are different (called `Data` and `SpanData`, respectively). Each of the types is partially typed out, where some fields overlap but have different types, and otherwise most fields are different. In a follow-up, these two types will be merged, but in the meanwhile we can convert between them via `IntoValue` and `FromValue`. The current approach carries two noteworthy caveats: 1. Roundtrip behavior is loosened, since the conversion function places certain event attributes into span.data. These are then cloned back into trace.data, where they did not reside in the original event. 2. `IntoValue` does not honor `skip_serialization`, so all typed fields are inserted into the `other` field as `Annotated::empty()`. This is a cosmetic issue in tests and leads to suboptimal performance, but these fields will be omitted properly in JSON serialization.
SDKs place span data for root spans into
event.contexts.trace.data
.Therefore, top-level span data was missing for metric extraction and in
indexed spans. This PR copies trace data over to the root span when
events are converted to spans.
The two types used for trace data and span data are different (called
Data
andSpanData
, respectively). Each of the types is partiallytyped out, where some fields overlap but have different types, and
otherwise most fields are different. In a follow-up, these two types will be
merged, but in the meanwhile we can convert between them via
IntoValue
and
FromValue
.The current approach carries two noteworthy caveats:
certain event attributes into span.data. These are then cloned back
into trace.data, where they did not reside in the original event.
IntoValue
does not honorskip_serialization
, so all typed fieldsare inserted into the
other
field asAnnotated::empty()
. This isa cosmetic issue in tests and leads to suboptimal performance, but
these fields will be omitted properly in JSON serialization.
Closes getsentry/sentry#73656