usage reporting: allow sending traces for unexecutable operations #6194
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8d39d2c:
|
In #5963 we added `!!metrics.captureTraces` to the condition for considering sending an operation as a trace to Studio. This makes sense for operations which start to execute (don't send something as a trace if we didn't record a trace for it!) but if the reason `captureTraces` is unset is because we never successfully resolved an operation, it still can be interesting to send a trace, for the sake of the Errors page. So we allow sending traces for unexecutable operations (though it still goes through our standard sampling algorithm). In order to make sure the recently added Trace.fieldExecutionWeight is set to the default value of 1 in this case, we set it when initially creating the Trace rather than in didResolveOperation. Fixes #6193.
glasser
force-pushed
the
glasser/trace-unexecutable
branch
from
22cc5c4
to
b5cf5be
Compare
|
I tested this PR locally and it works perfectly. |
glasser
added a commit
that referenced
this pull request
Mar 11, 2022
) In #5963 we added `!!metrics.captureTraces` to the condition for considering sending an operation as a trace to Studio. This makes sense for operations which start to execute (don't send something as a trace if we didn't record a trace for it!) but if the reason `captureTraces` is unset is because we never successfully resolved an operation, it still can be interesting to send a trace, for the sake of the Errors page. So we allow sending traces for unexecutable operations (though it still goes through our standard sampling algorithm). In order to make sure the recently added Trace.fieldExecutionWeight is set to the default value of 1 in this case, we set it when initially creating the Trace rather than in didResolveOperation. Fixes #6193.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #5963 we added
!!metrics.captureTracesto the condition forconsidering sending an operation as a trace to Studio. This makes sense
for operations which start to execute (don't send something as a trace
if we didn't record a trace for it!) but if the reason
captureTracesis unset is because we never successfully resolved an operation, it
still can be interesting to send a trace, for the sake of the Errors
page. So we allow sending traces for unexecutable operations (though it
still goes through our standard sampling algorithm).
In order to make sure the recently added Trace.fieldExecutionWeight is
set to the default value of 1 in this case, we set it when initially
creating the Trace rather than in didResolveOperation.
Fixes #6193.