You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using Mesh with the useNewRelic plugin, only the first request is sent to New Relic with all expected distributed tracing, limiting the granularity of the metrics we are able to monitor, including, for instance, how long was spent on different data sources.
For instance, with the following setup: .meshrc.yaml:
(customFetch set as Mesh uses undici, which isn't supported by New Relic by default, and requires a feature flag to be set)
When making individual requests for both dogs and currencies, both should appear with full distributed tracing, listed as dependencies, on New Relic. But only the first reaches New Relic. For instance, if the dogs query comes first (crucial bits at the bottom of the screenshots, where we can see any API calls made):
If the application is closed and a new instance booted up (pointing to a different New Relic app for this example), and the currencies query comes first:
(if these had been sent to the same New Relic application as the first example, the two dependencies would both appear).
It looks like manually instrumenting newrelic calls on our codebase suffers the same issue too.
I've experimented with using newrelic and useNewRelic without the use of Mesh and that works as expected. I've also used graphql-yoga without Mesh and that also works as expected. It looks like something in Mesh is causing an issue.
While debugging (eg. at this point), I did notice that when using Mesh, the first transaction is populated in newrelic, but every transaction after that is null. However, the transaction is available as expected during the useNewRelic plugin. I looked to see if different agents were being created but couldn't see any sign that was the case. It looks like the state is being lost at some point?
The issue doesn't look to be restricted to the handler used, locally I've found that the same issue happens with newOpenApi and in our production environment nothing is being recorded except for the first transaction of every instance.
The text was updated successfully, but these errors were encountered:
When using Mesh with the
useNewRelic
plugin, only the first request is sent to New Relic with all expected distributed tracing, limiting the granularity of the metrics we are able to monitor, including, for instance, how long was spent on different data sources.For instance, with the following setup:
.meshrc.yaml
:envelop-plugins.ts
:custom-fetch.js
:(
customFetch
set as Mesh usesundici
, which isn't supported by New Relic by default, and requires a feature flag to be set)When making individual requests for both
dogs
andcurrencies
, both should appear with full distributed tracing, listed as dependencies, on New Relic. But only the first reaches New Relic. For instance, if thedogs
query comes first (crucial bits at the bottom of the screenshots, where we can see any API calls made):If the application is closed and a new instance booted up (pointing to a different New Relic app for this example), and the
currencies
query comes first:(if these had been sent to the same New Relic application as the first example, the two dependencies would both appear).
It looks like manually instrumenting
newrelic
calls on our codebase suffers the same issue too.I've experimented with using
newrelic
anduseNewRelic
without the use of Mesh and that works as expected. I've also usedgraphql-yoga
without Mesh and that also works as expected. It looks like something in Mesh is causing an issue.While debugging (eg. at this point), I did notice that when using Mesh, the first transaction is populated in
newrelic
, but every transaction after that is null. However, the transaction is available as expected during theuseNewRelic
plugin. I looked to see if different agents were being created but couldn't see any sign that was the case. It looks like the state is being lost at some point?The issue doesn't look to be restricted to the handler used, locally I've found that the same issue happens with
newOpenApi
and in our production environment nothing is being recorded except for the first transaction of every instance.The text was updated successfully, but these errors were encountered: