-
Notifications
You must be signed in to change notification settings - Fork 155
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
downstreamXRayEnabled
/ traced
property behavior doesn't seem to align with X-Ray documentation
#493
Comments
Hi @jmm,
To be honest, I am not sure why we move the
I believe this is just an optimization - it means the trace is expecting another update from the downstream traced service and should be easily ready for an update. In practice a trace is just a collection of segments, it can always have new segments added, so again I don't think X-Ray actually behaves any differently in this case. |
Hi @willarmiros, thanks for your reply.
So the X-Ray concepts :: Subsegments documentation says:
I'm not sure if that's what you mean by de-duplication, but this indicates that there will always be a client-side subsegment, and there will always be a corresponding top-level segment -- that will either be inferred, or provided by another instrumented service. (And there's no indication that this behavior is related to the In my test, regardless of the value of So However, the AWS X-Ray segment documents documentation suggests that while the tracing is in progress there may be some difference in behavior between the time the subsegment for the call to the instrumented service is created and the time that service uploads its segment. It's unclear what that difference would be though. Again, I don't know what "broken" means here:
It's also unclear what would happen if So if the X-Ray documentation regarding the And if
There must be some point to setting it, right? |
Hello, I'm confused about the behavior of the
downstreamXRayEnabled
parameter tocaptureHTTPsGlobal
. The documentation and behavior seem aligned that whentrue
, a top-leveltraced: true
property is created on the subsegment.However, the AWS X-Ray segment documents documentation only documents
traced
as a property of thehttp.request
object of subsegments. Whereas the SDK seems to explicitly move it from there to the top-level of the subsegment.Can you please clarify the difference between that documentation and the behavior here?
Also, in practice, I can't observe a meaningful difference between
downstreamXRayEnabled: false
(or omitted) anddownstreamXRayEnabled: true
. In thetrue
case I can see a top-leveltraced: true
property on the subsegments in the raw trace data, but I can't observce a difference in the trace as displayed in the console either for a request to an instrumented service or a non instrumented external service (a subsegment that winds up withinferred: true
).It's also not clear what the segment documents documentation means by:
The text was updated successfully, but these errors were encountered: