Refactor Event API to reflect spec changes#6318
Refactor Event API to reflect spec changes#6318jack-berg merged 2 commits intoopen-telemetry:mainfrom
Conversation
|
Leaving as a draft PR since this depends on #6316. But wanted to open it up anyway to get eyes on the API ergonomics. |
|
This will be quite a bit easier to review after rebasing after #6316, but I'm onboard with this approach. |
dd11124 to
d963b68
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6318 +/- ##
============================================
+ Coverage 91.06% 91.07% +0.01%
- Complexity 5732 5751 +19
============================================
Files 625 626 +1
Lines 16748 16782 +34
Branches 1713 1718 +5
============================================
+ Hits 15252 15285 +33
- Misses 1002 1003 +1
Partials 494 494 ☔ View full report in Codecov by Sentry. |
|
Ready for review! |
|
@jack-berg this API doesn't seem to accommodate setting a primitive data type to the |
Yup. I figured we'd hold off on that until someone asked for it. Setting the body to something other than a kvlist would look something like |
|
jack-berg#18 |
breedx-splk
left a comment
There was a problem hiding this comment.
Yeah this is great! I don't see any reason to hold this up. Let's roll!
I did have a few comments/questions, and I want to make sure that we're able to consider expanding on this in the future to 1) make spec compliant, 2) convenient.
Thanks again for taking all this on. 👍🏻 Much appreciated.
| } | ||
|
|
||
| @Override | ||
| public void emit(String eventName, Attributes attributes) {} |
There was a problem hiding this comment.
I think it's fine for now, but removing this requires the user wanting to use the "empty" event (where there is no payload, which spec allows) to do eventLogger.builder("foo").build() which is fine, but could have improved ergonomics in the future. 👍🏻
I also respect that we're sensitive to API surface area. 🙃
| values.add(AnyValue.of(val)); | ||
| } | ||
| return put(key, AnyValue.of(values)); | ||
| } |
There was a problem hiding this comment.
The test coverage on these default methods comes from the SDK. Do we care about having direct coverage from the API itself?
| if (!hasTimestamp) { | ||
| logRecordBuilder.setTimestamp(clock.now(), TimeUnit.NANOSECONDS); | ||
| } | ||
| logRecordBuilder.setAttribute(EVENT_NAME, eventName); |
There was a problem hiding this comment.
👍🏻 Solid test coverage on these code paths too....easy to overlook, so thanks!
|
Will plan on merging after today's Java SIG if there are no additional comments. |
Reflects changes in open-telemetry/opentelemetry-specification#3772 and open-telemetry/opentelemetry-specification#3749.
Previously attempted in #6001.
Summary of changes:
put(String key, ? value)types added which add information to the body. The spec currently seems to be thinking that fields in an event body are not attributes. Because of this, there are not overloads for put which accept the attributes.setAttributes.INFO=9.Usage example of the API:
Part of the goal of bundling several breaking changes into a single release to reduce churn.
cc @breedx-splk