Failled queries are not recorded in the report

[the-glu]

It seems that failed queries that are retired are not exposed in the report, potentially hidden issues and limiting debugging.

Example:

• First query timeout
• Second query return an error

The report will only contain the second query.

I would expect it both to be present.

Observed at least on flight injection during slow updates tests.

[BenjaminPelletier]

I think this is a good idea and has strong likelihood of improving future user experiences when trying to troubleshoot. But, I think this is an enhancement rather than a bug as query_and_describe is currently behaving as intended, returning one query in response to a request to make a query. I do agree that potentially returning multiple queries (the first n-1 failing due to some retryable reason) in response to a request to make one query is a more robust approach. But, I don't think this will be a small change as the query architecture is perhaps the feature with the largest multiplicity of usage in the codebase. Any suggestions on how to go about making this change? I don't think it would be feasible to change the return signature of query_and_describe in one PR. Perhaps we could add a behavioral variant like query_and_describe_n which returns all the queries and start migrating query_and_describe usages to query_and_describe_n in batches until everything is migrated and we can delete query_and_describe?

[the-glu]

Any suggestions on how to go about making this change?

I worked on it on #1298 , and yes, to avoid major changes / rewrite, I took the approach of adding a field to the Query object, pointing to an optional, previous query. The previous query represent a failed query that lead to the current one (naming probably need some improvement).

With that, query_and_describle only changes are on the retry logic, and clients may, if they want, follow the tree of previous queries (eg. record_queries, that will just call himself on the previous query first, before doing the actual record).

(That was the reason of adding support of 'Self' to implicitdict)