Should we consider using a higher value than 10 seconds here, so that it would exceed the timeout, just to verify that scenario works OK?

Sure. I will set it to 120 secs.

Thinking about the test case, I think that a big delay would be equivalent to the no_answer case, what do you think?

Not exactly sure, I assumed that there is a difference in that the "No Answer" case would return immediately with an error such as "No connection could be made because the target machine actively refused it", whereas the "Slow Answer" would keep the request going until the timeout occurs. Does that make sense to you?

Right now, the "no answer" case will keep the connection open until timeout (I named it "no aswer" because it keeps the connection open but never really answers). The 404 and 500 cases return error codes. The slowAnswer case answers with a big delay, which also causes a timeout, but in real time, when the agent answers with a big delay, the tracer already has sent the spans and the sample program has already exited, so we would be testing the same case as "no answer". I think that it makes sense to will keep only one timeout case.

Ah, got it! So yes, perhaps it makes sense to keep just one of them, since in practice they are equivalent. @andrewlock WDYT?

Yes, I agree.

The "no answer" case is really a special case, where we can't make a connection to the agent (i.e. there's no agent listening on that port etc). We probably still want to test that (including for named pipes + system tests), but it's fundamentally different to these tests, as we won't get traces then either. For that case we just want to confirm that the app can run without crashing, and exits in a timely matter.

In the "no answer" case we still receive the traces in the test since the tracer seems to send them even if the agent does not answer.

If you think that the PR is ready, please approve and I will merge it.

In the "no answer" case we still receive the traces in the test since the tracer seems to send them even if the agent does not answer.

I think we need to:

• Remove either the "no answer" case or the timeout case (as they're functionally the same), which you've already done ✅
• Create a new test, that doesn't set up a mock agent, so the app tries to send to a non-existent agent. Confirm that the app exists quickly (normally) and there's no crash.

That second one could be a separate PR if you prefer 🙂

Yes, if it is ok, I would prefer to implement this test in a separate PR.

Technically I think this closes the handler, so this is a different test from the "no answer" one in TCP (premature disconnect vs timeout) but I don't know if that matters too much

Done!

In the "no answer" case we still receive the traces in the test since the tracer seems to send them even if the agent does not answer.

I think we need to:

• Remove either the "no answer" case or the timeout case (as they're functionally the same), which you've already done ✅
• Create a new test, that doesn't set up a mock agent, so the app tries to send to a non-existent agent. Confirm that the app exists quickly (normally) and there's no crash.

That second one could be a separate PR if you prefer 🙂