When using the monitoring.listTimeSeries method, the default calloption specifies autoPaginate: true. In this mode, the call is wired up with gax in a way that its pagination code ignores response fields other than the response item list and the next page token.

In this API method, however, there's an important field called executionErrors, which can contain errors like:

[{"code":14, "details":[], "message":"Query results don't include data from regions: europe-central1, europe-west1. Please retry in a few minutes."}]

In extreme cases, this method can return 0 results due to these underlying problems.

There's a clear solution here of course, I can manage paging myself and then I can inspect this field and act accordingly.

However, this can easily cause problems for developers not fully aware of this field and the internals of how gax manages auto-paging.

There can be multiple ways the library could handle these problems:

• Either retry the api call for the individual page
• Or reject the entire call in this case.
• Maybe expose an aggregate of the executionErrors in the response.

I understand that the API side of this service made the decision to return partial errors, so that the clients can decide if they are happy with the partial results or retry if not. However, as a developer calling this API with this client library, I would prefer a default where I can be sure that the results are complete if no errors was thrown.

I also understand that the development of such a feature would likely need extensions in the underlying gax library too.