Skip to content
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

RabbitMQ: NR agent version 8.39.2 overwrites message headers #639

Closed
witoldsz opened this issue Jul 12, 2021 · 9 comments · Fixed by #648 or #649
Closed

RabbitMQ: NR agent version 8.39.2 overwrites message headers #639

witoldsz opened this issue Jul 12, 2021 · 9 comments · Fixed by #648 or #649
Assignees
Labels
bug Something isn't working community To tag external issues and PRs

Comments

@witoldsz
Copy link

witoldsz commented Jul 12, 2021

Description
After upgrading NewRelic agent 8.37.0 to 8.39.2 our services started to fail due to missing headers in RabbitMQ messages.

Expected Behavior
New Relic should not overwrite application's headers with it's own.

Steps to Reproduce
Application written in F# 5, publishing messages looks like this (simplified)

let ch = conn.CreateModel()
let props = ch.CreateBasicProperties()
props.Persistent <- true
props.ContentType <- "application/json"
props.Headers <-
    Map.ofList [ "trace", trace |> Array.map (fun it -> it.ToString()) :> obj
                 "publisher", appName :> obj
                 "ts", now |> Utils.instantToISOString :> obj ]
ch.BasicPublish(exchange, routingKey, props, ReadOnlyMemory(Encoding.UTF8.GetBytes body))

Your Environment

  • Linux 5.4
  • dotnet 5.0
  • RabbitMQ 3.6 server
  • Nuget: "RabbitMQ.Client" Version="6.2.1"
  • newrelic-netcore20-agent_8.39.2.0_amd64.tar.gz

Additional context
Nothing yet, work in progress…

@witoldsz witoldsz added the bug Something isn't working label Jul 12, 2021
@witoldsz
Copy link
Author

I think I have some lead. Take a look at the RabbitMQ API:
https://rabbitmq.github.io/rabbitmq-dotnet-client/api/RabbitMQ.Client.IBasicProperties.html#RabbitMQ_Client_IBasicProperties_Headers
IDictionary<string, object> Headers { get; set; } this is IDictionary, not Dictionary).

However in:
https://github.com/newrelic/newrelic-dotnet-agent/blob/main/src/Agent/NewRelic/Agent/Extensions/Providers/Wrapper/RabbitMq/RabbitMqHelper.cs
there are expressions like:

Dictionary<string, object> headers = carrier.Headers as Dictionary<string, object>;
if (headers == null) …

Correct me if I am wrong, but it will always result in null unless the System.Collections.Generic.Dictionary<TKey,TValue> class is used by an application.

Now, in my case, the props.Headers <- Map.ofList [ … ] ← not a Dictionary, but still valid IDictionary instance.

@witoldsz
Copy link
Author

What's surprising is: why does it work in 8.37.0… So, when I have upgraded NR to 8.39.2 – the only headers our application messages had: X-NewRelic-ID and X-NewRelic-Transaction, when using 8.37.0 the only headers are our own, i.e. publisher, trace and ts.

It looks like NR 8.37.0 does not intercept the:
BasicPublish(this IModel model, string exchange, string routingKey, IBasicProperties basicProperties, ReadOnlyMemory<byte> body)
at all and this is why our application does work with older version of the agent, and crashes with the newer.

@lstachowiak
Copy link

I have the same issue. Thanks for reporting! I hope it will be fixed soon! 🤞

@JcolemanNR JcolemanNR added the community To tag external issues and PRs label Jul 13, 2021
@JcolemanNR
Copy link
Contributor

Thank you for the bug report and investigation @witoldsz! As you identified, we did recently add instrumentation to some RabbitMQ calls.

The team discussed this issue in the standup today and we are looking at a fix.

@nr-ahemsath
Copy link
Member

Thanks for writing this up @witoldsz. I agree with your analysis of what the issue is. Hopefully we can get a fix out soon.

@nr-ahemsath
Copy link
Member

@witoldsz @lstachowiak We just merged a PR that should fix this issue, which auto-closed this issue. The fix will be available in the next release. I am not sure when we plan to do the next release, it might be as early as next week. Thanks again for the report and the analysis.

@lstachowiak
Copy link

thank you for such a quick response!!!

@witoldsz
Copy link
Author

witoldsz commented Jul 14, 2021

@nr-ahemsath thank you. I saw the PR and as far as I can tell, it will crash our application: #648 (comment)
However, I have never written a line of code in C# in my life, so I might be wrong on that. Please check it. Thanks!

@tehbio
Copy link
Contributor

tehbio commented Jul 14, 2021

@witoldsz You're right - the FSharpMap dictionary is read-only. I've pushed some extra checks to handle this case in a new PR here.

@tehbio tehbio reopened this Jul 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working community To tag external issues and PRs
Projects
None yet
5 participants