Usage reporting: operations that can't execute still can make interesting traces #6193
Comments
glasser
added a commit
that referenced
this issue
Mar 10, 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.
glasser
added a commit
that referenced
this issue
Mar 10, 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.
glasser
added a commit
that referenced
this issue
Mar 10, 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.
|
The fix is released in v3.6.4. |
glasser
added a commit
that referenced
this issue
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.
In #5963 we added
!!metrics.captureTracesto 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 reasoncaptureTracesis 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.The text was updated successfully, but these errors were encountered: