-
Notifications
You must be signed in to change notification settings - Fork 19
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: Add support for event body fields #297
Conversation
The PR supersedes #236 as discussed in tools sigs this morning. |
crates/weaver_resolver/data/registry-test-4-events/registry/browser-event.yaml
Outdated
Show resolved
Hide resolved
crates/weaver_resolver/data/registry-test-4-events/registry/browser-event.yaml
Outdated
Show resolved
Hide resolved
crates/weaver_resolver/data/registry-test-4-events/registry/browser-ref-event.yaml
Outdated
Show resolved
Hide resolved
crates/weaver_resolver/data/registry-test-4-events/registry/browser-event.yaml
Outdated
Show resolved
Hide resolved
crates/weaver_resolver/data/registry-test-4-events/registry/browser-ref-event.yaml
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR represents a lot of work and is overall really good. However, my main concern is the lack of alignment between the concept of a body field and the concept of embedded/aliased attributes. Depending on how this discussion ends, the implications for this PR could be more or less significant.
crates/weaver_resolver/data/registry-test-4-events/registry/browser-ref-event.yaml
Outdated
Show resolved
Hide resolved
5111ee7
to
42b7a6c
Compare
6832983
to
88ac690
Compare
f4a3c3e
to
82ac35d
Compare
82ac35d
to
785d84b
Compare
Please also see comments and discussion topics in #365 |
785d84b
to
b8a97a6
Compare
b8a97a6
to
2d7ad64
Compare
AnyValue PR and this PR now have the same (common) set of changes. |
- type - brief - note - stability - examples
2d7ad64
to
d836d08
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me now.
I'm still unhappy with the direction our tests have been going in and I'd much prefer finer-grained, feature or regresison focused tests, but we can clean that up later.
crates/weaver_resolver/data/registry-test-4-events/registry/trace-gen-ai.yaml
Outdated
Show resolved
Hide resolved
crates/weaver_resolver/data/registry-test-4-events/expected-registry.json
Outdated
Show resolved
Hide resolved
crates/weaver_resolver/data/registry-test-4-events/expected-registry.json
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
crates/weaver_resolver/data/registry-test-4-events/observed-events.json
Outdated
Show resolved
Hide resolved
crates/weaver_resolver/data/registry-test-4-events/registry/trace-gen-ai.yaml
Outdated
Show resolved
Hide resolved
|
||
{% for event in ctx.events %} | ||
## Event `{{ event.name }}` | ||
## Event `{{ event.id }}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question: Why using id
and not name
here?
Not blocking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the top level "name" will still exist on the event
type, its just the AnyValues
that will now only have the id
(and no name
), and this is just local test code.
| map(. + { | ||
event_namespace: (if .id | index(".") then (.id | split(".") | .[0:-1] | join(".")) else "other" end) | ||
}) | ||
| sort_by(.event_namespace, .id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question: Why use event_namespace
instead of root_namespace
, as with the other signals? I just want to avoid the same kind of issues we had in the past with name
and metric_name
, which made it harder to generalize without providing significantly higher value for the UX.
Not blocking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to this from me. We should avoid diverging here, although IIUC this is just testing code right?
We can clean this up later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is just testing code. And for events the entire "event_namespace" is important and not just the "root_namespace"...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once the merge with the other PR (AnyValueSpec) is done, and the few minor corrections mentioned in my comments are made, I see no problem with creating a release with this PR. Please update the CHANGELOG.md
to announce the support of events in Weaver (section [Next]).
However, as a precaution, I think it would be a good idea to check the backward compatibility with the older registries. The previous version was able to check all versions from 1.21.0 to the latest one. You can test each version with the following command line.
cargo run -- registry check -r https://github.com/open-telemetry/semantic-conventions/archive/refs/tags/v1.21.0.zip[model]
Thanks for all your hard work on this!
@@ -490,6 +491,73 @@ impl Examples { | |||
), | |||
} | |||
} | |||
|
|||
/// Validation logic for the any_value. | |||
pub(crate) fn validate_any_value( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this function in the attribute.rs
file instead of any_value.rs
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept it here with the other "Examples" validate so that there was only one location for handling "Examples"...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Local backward compat check past with the expected warnings about examples SHOULD be of type string[]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. So we are ready to go?
…resolved schema - simplify validate_any_value_examples - Reduce the test yaml events to smaller set - Removed observed file
Adds support for the event body fields reusing the existing
event
type.event
(Span) definitionevent
definition as an extension of the existing span definitionBody
(optional) definition which supports a collection offields
or a singlestring
valuetype
of string or map