Closed intens-pavlas closed 3 weeks ago
Hi @intens-pavlas
Thanks for bringing this to our attention, I will look into this and come back to you shortly.
Thank you! It's been a great experience so far. My first tests against the current master seem to be fine. Do you have any insight when the next release might be published so we can reference the new nugget package?
Hey @intens-pavlas
I am preparing the patch to be released today as v23.3.4
Thanks for the quick turnaround, I'm looking forward to it.
Hey @intens-pavlas
v23.3.4
is now up on NuGet, let me know if you have any issues going forwards.
Thanks!
Hi @josephcummings
Using v23.3.4 of the libraries and subscribing to a category stream with resolveLinkTos = true
the trace writer fails to resolve the traceid from the resolved event metadata if I'm understanding it correctly.
TraceSubscriptionEvent()
returns early if the OriginalEvent.ContentType != "application/json"
. Can this be tested differently depending on the configuration of the subscription?
src/EventStore.Client/Common/Diagnostics/ActivitySourceExtensions.cs#L36
Hey @paddyb, We removed the condition that was causing it to return early. We also now extract the trace context from the Event instead of the OriginalEvent to account for category stream events. Please try out 23.3.5 and let us know how it goes.
Tested it there @w1am and it's working just fine now. Thank you for the quick turnaround
Describe the bug If an event has application/octet-stream metadata (we're using protobuf serialization) and open telemetry is active at the same time then an Exception is thrown in TraceSubscriptionEvent when subscribed on the stream. It is not handled and it is propagated to a client code, where it prevents the event from being received.
To Reproduce I found some similiraties with https://github.com/EventStore/EventStore-Client-Dotnet/issues/310 .
I was able to borrow his minimal example and modify it to reproduce my behavior.
Replicated code
Steps to reproduce the behavior
"eventstoredb"
JsonDocument
Expected behavior I think the exception should never be thrown in the first place. However catching the exception in
EventMetadataExtensions.cs:24
->
or
Checking for content type in
EventStoreClient.Subscriptions.cs:231
->
both worked well for me as a quick fix.
Actual behavior The exception is thrown before the event is passed to the client code - preventing the event from being received.
Config/Logs/Screenshots
EventStore details
Additional context What is little odd to me is even before this all happens. In
EventMetadataExtensions.cs:54
TryInjectTracingMetadata
there is an attempt to parse stream into json document and if it fails, it will pass through original stream, which probably allows bad characters to propagate through. Maybe it shouldn't be even initiated when arbitrary application/octet-stream is sent. Or there should be some other way to trace such metadata. This is probably up to you to evaluate further.