[uss_qualifier] NetRID heavy traffic concurrent: handle concurrent query exceptions

[Shastick]

This is a fix for #1078, which should allow uss_qualifier to proceed without crashing out when mime-type errors occur, while keeping around request details for possible troubleshooting.

[mickmis]

I don't think it is desirable to introduce such specific work-around in the low-level class AsyncUTMTestSession, moreover it has not been requested in #1078. In addition it is quite valid for AsyncUTMTestSession to let bubble up any (aiohttp) exception raised during a request as we might want to handle that up the stack. Including a content type exception.

Since scenario HeavyTrafficConcurrent is the only significant caller of AsyncUTMTestSession (except from the prober as well, which we can ignore here), it is IMO enough to intercept the exception there (and be more specific: aiohttp.ClientError is probably a good candidate rather than the generic Exception).

That would be enough to address #1078 without having to come back to it later. And simpler. WDYT?

[Shastick]

Since scenario HeavyTrafficConcurrent is the only significant caller of AsyncUTMTestSession (except from the prober as well, which we can ignore here), it is IMO enough to intercept the exception there (and be more specific: aiohttp.ClientError is probably a good candidate rather than the generic Exception).

What bothers me with the 'just catch any exception from the future awaiting on all the coroutines' approach is that we lose any detail relevant to the request that was made. If we are happy with discarding the request, an approach we can use is to have return_exceptions=True passed to gather, which will return an exception instead of a result for any failing coroutine. At least we can record the details of the successful queries.

Though, in an ideal world uss_qualifier is able to show the request that was made for a failed response, as it may prove useful users.

edit: I can reach the desired effect without the changes in AsyncUTMTestSession by a few changes in the boiler-plate within HeavyTrafficConcurrent (catching the exception at a lower level and returning available details)

[Shastick]

@mickmis the present solution is local to the problematic scenario, while it still keeps as much information as possible about the failed request.

[mickmis]

@mickmis the present solution is local to the problematic scenario, while it still keeps as much information as possible about the failed request.

Neat solution. Thanks!