feat(reporting): Add reportTiming option to EngineReportingOptions#3918
Conversation
39d97cb to
b3f6862
Compare
|
@jsegaran great to see this change is being made, we at Glassdoor are eagerly waiting for this change to get published. @trevor-scheer @abernix -- Thanks for your reviews. |
a751239 to
41f2129
Compare
There was a problem hiding this comment.
Looking good! I've left a couple comments/thoughts within.
Additionally, this should:
-
Be re-based on the
release-2.14.0branch now that #3988 has landed there and is the new base for theapollo-engine-reportingplugin. -
Introduce some tests within the
apollo-engine-reportingpackage that ensures this is behaving as expected. -
Introduce some(Copy paste fail)
f36fcab to
1b07df0
Compare
1b07df0 to
334d77e
Compare
e552ba9 to
ce57d65
Compare
abernix
left a comment
There was a problem hiding this comment.
Very excited for this to land! I'm thinking we'll get this into the 2.14.0 release, and I've left a few comments within that seem worth addressing.
Thanks for working on this! 🎉
4b64147 to
66559c8
Compare
|
Thanks for the review. I rebased the PR off #4084 since I assume that will be merged first. |
f7d857d to
977a89e
Compare
66559c8 to
fdf2445
Compare
|
To match |
|
Just noticed the commit that was pushed to this that switched to Whatever decision is made, please update the title and description of the PR. 😄 |
|
I agree with Jesse that the PR desc needs to be updated and that it would make more sense for the name to be parallel with reportSchema but this is fine. |
traceReporting option to EngineReportingOptionsreportTiming option to EngineReportingOptions
Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: Renovate Bot <bot@renovateapp.com>
|
Updated the name to |
glasser
left a comment
There was a problem hiding this comment.
I didn't do a full rereview but assuming you consistently got the name changed I think this is still fine?
abernix
left a comment
There was a problem hiding this comment.
LGTM, though similarly to @glasser, I have not given it a full re-review though I've looked at it in the past. I'm going to retarget this to merge to release-2.15.0. Given the commits in this branch, is this a candidate for squashing?
|
Yea I think squashing this seems good. |
|
Shipped in |
Previously, we were leveraging `sendReportsImmediately` to ... do exactly that even though these tests don't need to send reports _at all_!. This was purely a hack to make sure that we don't need to wait for the Engine Reporting Agent to eventually fail (after 5 seconds or whatever its reporting interval is). This new `reportTiming` option is available with the below-linked PR, so we can now clean this up a bit. This has the added advantage of not hitting our actual reporting endpoint with an invalid API key, and having the logs spew errors about failures in delivering those doomed reports. Ref: #3918
Previously, we were leveraging `sendReportsImmediately` to ... do exactly that even though these tests don't need to send reports _at all_!. This was purely a hack to make sure that we don't need to wait for the Engine Reporting Agent to eventually fail (after 5 seconds or whatever its reporting interval is). This new `reportTiming` option is available with the below-linked PR, so we can now clean this up a bit. This has the added advantage of not hitting our actual reporting endpoint with an invalid API key, and having the logs spew errors about failures in delivering those doomed reports. Ref: #3918
Previously, we were leveraging `sendReportsImmediately` to ... do exactly that even though these tests don't need to send reports _at all_!. This was purely a hack to make sure that we don't need to wait for the Engine Reporting Agent to eventually fail (after 5 seconds or whatever its reporting interval is). This new `reportTiming` option is available with the below-linked PR, so we can now clean this up a bit. This has the added advantage of not hitting our actual reporting endpoint with an invalid API key, and having the logs spew errors about failures in delivering those doomed reports. Ref: #3918
This PR adds a
reportTimingapi. It takes a function with parameterGraphQLRequestContextDidResolveOperationorGraphQLRequestContextDidEncounterErrorswhich returns a promise resolving to a boolean, or it takes a boolean. If the api resolves to false the agent will not instrument the operation or report the query. If the return type is true the agent will act as default and instrument and report the query to Apollo Graph Manager.Create a new
reportTimingapi under EngineReportingOption that allows configuration of whether an operation should be traced. Previously there was no way to turn off instrumentation and tracing of requests if anapiKeywas provided. The api allows turning off tracing on all requests or selectively turning off tracing based on a specific request shape.The option can be set via the engine config, and the default is true where every trace gets instrumented and sent to Apollo Graph Manager.