Replicate similar span tracking on the ResponseManager side
Implementation
For now, when we receive a new incoming request, we'll create a span from root graphsync context (later we want to find a way to hook this span up to any referenced data transfers, if they have their own tracing context, but we're not gonna try that yet).
Our top level span should last the length of the request until the request is finished. The answer to "when is this" is a bit more complicated than it may seem. There are several paths to the true end of the request in ResponseManager (I just realized how not great this is btw -- perhaps a different ticket):
bonus Important red herring path: finishTask. finishTask is called when the query has finished executing, meaning all selector data has been read from disk and queued for send. BUT all data has not been sent
We should also track as individual spans for startTask, finishTask, and each run of the query executor.
rvagg
commented
2 years ago
What
Replicate similar span tracking on the ResponseManager side
Implementation
For now, when we receive a new incoming request, we'll create a span from root graphsync context (later we want to find a way to hook this span up to any referenced data transfers, if they have their own tracing context, but we're not gonna try that yet).
Our top level span should last the length of the request until the request is finished. The answer to "when is this" is a bit more complicated than it may seem. There are several paths to the true end of the request in ResponseManager (I just realized how not great this is btw -- perhaps a different ticket):
bonus Important red herring path: finishTask. finishTask is called when the query has finished executing, meaning all selector data has been read from disk and queued for send. BUT all data has not been sent
We should also track as individual spans for startTask, finishTask, and each run of the query executor.