Async traces #225
Async traces #225
Conversation
| const maxTracePollRetry = 5 | ||
|
|
||
| func donePollingTraces(job tracePollReq, currentResults TestRunResult) bool { | ||
| // we're done if we have the same amount of spans after polling `maxTracePollRetry` times |
There was a problem hiding this comment.
Nice. I was thinking of doing something similar.
| func (tp tracePoller) requeue(job tracePollReq) { | ||
| go func() { | ||
| fmt.Printf("requeuing result %s for %d time\n", job.result.ResultId, job.count) | ||
| time.Sleep(500 * time.Millisecond) |
There was a problem hiding this comment.
I think that this value and maxTracePollRetry should be configurable (maybe interval and retries options). If the service under test uses a SpanBatchExporter, updates are sent in batches every X seconds. And that interval is configurable by the application.
2.5s works only if the service under test doesn't send tracing logs in batches.
So, let's say the application uses a Batch exporter that sends updates every 10 seconds. At moment X, we have 10 spans in the trace, the application might have generated a few more, but they will only be exported to Jaeger at moment X+10s. However, at moment X+2.5s we will have get traces 5 times and the number of spans haven't changed since moment X, and we will consider the trace complete. However, that is not true. In this case, we must wait at least 10 seconds to consider the trace complete. As this is something that might change from application to application, we should allow the user to define those values.
There was a problem hiding this comment.
That makes sense. I'll address this in a separated PR, since it kindda works like this and we need to unblock
This PR refactors the test execution and trace polling into two different working queues.
Changes
Fixes
Checklist