Reviewed By: Kuba386

Would have been good if there was mentioned which aspects were reviewed, what was tested.

Having Async in the name was not really informative

It was informative, because it informed the reader that those requests are handled asynchroneously.
It is arguably misleading if all stored requests are handled asnychroneously, and I guess a request container implies asynchroneous serving.
Not really informative and not informative is the same, so "really" should be avoided.

was not really informative and made it awkward to reuse for non-async code.

'Awkward' is subjective and not informative either.
If there were sync request member variables, it actually would be better to have the distinction.

I guess one can agree to the diff if there aren't any sync requests that I didn't stumble upon.

In rP22305#34318, @elexis wrote:

If there were sync request member variables, it actually would be better to have the distinction.

The struct's name should reflect its content, not how it is handled. The contents of these structs are path requests (with an optional ticket number which is only useful when async).
Both sync and async code could use the structures (and in fact probably should - I can't recall if I have a diff for that).
The callers never see these structures anyways, since they call functions where Async is explicitly in the name.

I guess we can debate if m_ShortPathRequest and m_LongPathRequest should have kept the async in their name, but I don't think it's very useful.