-
Notifications
You must be signed in to change notification settings - Fork 377
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
Add support for GraphQL 2.0 #1982
Conversation
@@ -7,11 +7,11 @@ module GraphQL | |||
# GraphQL integration constants | |||
# @public_api Changing resource names, tag names, or environment variables creates breaking changes. | |||
module Ext |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These Ext
changes were done for all integrations, except GraphQL in #1800. Because GraphQL changes involved upstream changes, we held off until now to make them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming in this PR that the next version of graphql (currently 2.0.6) will contain our upstream changes. If not, I'll update our code to address that, but I believe the current implementation is ready to go.
The next version has been released as 2.0.7: https://github.com/rmosolgo/graphql-ruby/blob/master/CHANGELOG.md .
Unfortunately, the code added in rmosolgo/graphql-ruby#4038 is
if defined?(Datadog::Tracing::Metadata::Ext) # Introduced in ddtrace 1.0
span.set_tag(Datadog::Tracing::Metadata::Ext::TAG_COMPONENT, 'graphql')
span.set_tag(Datadog::Tracing::Metadata::Ext::TAG_OPERATION, key)
end
and if I'm looking at this correctly, this code DEPENDS on this PR. Aka I think 2.0.7 is broken for customers on 1.0.0.beta2, because beta2 has Datadog::Tracing::Metadata::Ext
but no TAG_COMPONENT
.
My suggestion would be to possibly submit a new PR upstream to change defined?(Datadog::Tracing::Metadata::Ext)
into defined?(Datadog::Tracing::Metadata::Ext::TAG_COMPONENT)
, which would make graphql fallback to the previous behavior on beta1/2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, that makes sense.
Nothing we can do in this PR, unfortunately.
I'll take note of this so we either quickly release a new version of ddtrace or update upstream.
Codecov Report
@@ Coverage Diff @@
## master #1982 +/- ##
==========================================
+ Coverage 97.71% 97.74% +0.02%
==========================================
Files 1004 1004
Lines 50628 50651 +23
==========================================
+ Hits 49472 49508 +36
+ Misses 1156 1143 -13
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spotted a potential issue, but the issue is on the upstream side, not on this PR.
Otherwise it looks good, thanks for fixing this!
appraise 'contrib-old' do | ||
gem 'dalli', '< 3.0.0' | ||
gem 'graphql', '>= 1.12.0', '< 2.0' | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for the annoyance -- could you also enable this for 3.2 which I've merged recently in #1974 ?
Note: This also needs a fix on the Rakefile
to add 3.2 to the changed line.
Don't bother updating the gemfiles for 3.2 since we still haven't got it enabled in CI; we'll need to do it later anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
gem 'graphql', '>= 1.12.0', '< 1.13.0' # Newer versions are broken, needs to be investigated, see https://github.com/DataDog/dd-trace-rb/issues/1866 | ||
gem 'graphql' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify -- I'm assuming this PR also fixes #1866 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it does! Thank you for the reminder.
libddwaf (1.3.0.0.0.beta1-x86_64-linux) | ||
libddwaf (1.3.0.0.0.beta1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I... think this is harmless but just in case you see issues in CI I'll point out that this changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looks harmless, and CI is happy for now.
I'm not 100% sure how to avoid this with our current Rake task we use to update dependencies, but if it's an issue we'll circle back to this.
@@ -7,11 +7,11 @@ module GraphQL | |||
# GraphQL integration constants | |||
# @public_api Changing resource names, tag names, or environment variables creates breaking changes. | |||
module Ext |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming in this PR that the next version of graphql (currently 2.0.6) will contain our upstream changes. If not, I'll update our code to address that, but I believe the current implementation is ready to go.
The next version has been released as 2.0.7: https://github.com/rmosolgo/graphql-ruby/blob/master/CHANGELOG.md .
Unfortunately, the code added in rmosolgo/graphql-ruby#4038 is
if defined?(Datadog::Tracing::Metadata::Ext) # Introduced in ddtrace 1.0
span.set_tag(Datadog::Tracing::Metadata::Ext::TAG_COMPONENT, 'graphql')
span.set_tag(Datadog::Tracing::Metadata::Ext::TAG_OPERATION, key)
end
and if I'm looking at this correctly, this code DEPENDS on this PR. Aka I think 2.0.7 is broken for customers on 1.0.0.beta2, because beta2 has Datadog::Tracing::Metadata::Ext
but no TAG_COMPONENT
.
My suggestion would be to possibly submit a new PR upstream to change defined?(Datadog::Tracing::Metadata::Ext)
into defined?(Datadog::Tracing::Metadata::Ext::TAG_COMPONENT)
, which would make graphql fallback to the previous behavior on beta1/2.
# Ensure invocation to #trace method targets the new namespaced public API object, | ||
# instead of the old global Datadog.trace. | ||
# This is fixed in graphql > 2.0.6. | ||
def tracer | ||
options.fetch(:tracer, Datadog::Tracing) # GraphQL will invoke #trace on the returned object | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this is fixed by rmosolgo/graphql-ruby#3978 which was in 2.0.3. So technically this would not be needed in [2.0.3, 2.0.6]
.
(I do realize that the fallback_transaction_name
fix is only in 2.0.7
, and so we need the patch anyway BUT I would suggest fixing or even deleting the comment, since it's a bit misleading, and a bad comment is worse than no comment :P)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had this comment mentioning version 2.0.3
at first, but purposefully updated it to 2.0.6
for a reason, but I don't recall why. I'll updated it to 2.0.3
.
Fixes #1325.
Fixes #1866.
This PR adds support for GraphQL 2.x series.
Additional work is done in an upstream PR.
Also, this PR backfill a few parts of the upstream integration to support ddtrace 1.0 on versions of the graphql gem that do not have the upstream PR changes.
In sum, this PR:
I'm assuming in this PR that the next version of graphql (currently 2.0.6) will contain our upstream changes. If not, I'll update our code to address that, but I believe the current implementation is ready to go.