Add test for TracingFilter #2847
Conversation
github-project-automation
bot
moved this from PRs In Progress
to Ready to merge
in Basic Kanban Board
| .containsEntry("rojo", "00f067aa0ba902b7") | ||
| .containsEntry("congo", "t61rcWkgMzE"); |
There was a problem hiding this comment.
Nit: using variable or constant here? t61rcWkgMzE -> congoValue?
| .containsEntry("rojo", "00f067aa0ba902b7") | |
| .containsEntry("congo", "t61rcWkgMzE"); | |
| .containsEntry("rojo", spanId) | |
| .containsEntry("congo", "t61rcWkgMzE"); |
| Map<AttributeKey<?>, Object> attributes = span.getAttributes().asMap(); | ||
| assertThat(attributes) | ||
| .containsEntry(stringKey(TracingFilter.REALM_ID_ATTRIBUTE), "POLARIS") | ||
| .containsEntry(stringKey(TracingFilter.REQUEST_ID_ATTRIBUTE), "12345"); |
There was a problem hiding this comment.
side note: my thinking was to reuse request ID from OTel (e.g. trace ID + span ID). Since we're moving towards "correlation", I think it makes sense to integrate with the existing OTel standard. In that case it should not be necessary to add REQUEST_ID_ATTRIBUTE to the span, but someone inspecting the response headers would be able to correlate them to the trace.
If OTel is present, what is the value of Polaris accepting / generating yet another request ID?
Are we considering the Polaris request ID as a first class feature of the protocol (REST API flowing into Events) as opposed to a "helper" or "observability" feature?
If OTel is not present, we can certainly generate a fresh request ID.
There was a problem hiding this comment.
OK, let's move this conversation to the dev ML:
https://lists.apache.org/thread/bb1qyxjt827t3tomv2xp0s1kovxjsp94
4 participants
TracingFilterwas lacking a proper test.After discussing with @dimas-b on #2757 I decided to create a test to illustrate two things: