bwurtz999

[mellow trout]

Hi 👋 thank you for sharing that request ID, do you have an example of one where you saw this run faster so I can compare those requests?

[jolly portal]

Yes, one minute

Oh OK so I think I've found why they are different, but this leads to a new problem

I have my reader turned off to simulate what happens if the reader is ever unreachable

Sorry let me start over

I actually don't have a request that is shorter with the same error, but when the error is Reader is busy processing another request (req_IHZCGM1dphyQeV) the error is returned very quickly

I had tested the reader being offline a few weeks ago and I thought the error was returned very quickly. I don't have one of those to compare unfortunately

But now all of the Reader unavailable errors are taking between 7-12 seconds to return and it's making my app extremely slow and nearly unusable

[mellow trout]

I haven't seen this behavior before, but my initial thought is that it likely makes sense. My (possibly naive) assumption is that those functions have a timeout window for the request to the reader that must expire before the reader is considered unreachable, to allow time for slow network connections.

[jolly portal]

I could be wrong, but I believe this is new. I had tested this scenario (reader offline) in the past and I don't believe I experienced this

Could this be new? Or am I just wrong?

Is it safe to assume that this behavior will not change (i.e.: I should adjust my app accordingly)?

[mellow trout]

I'm not sure offhand, and will need to see if I can find a definitive answer on that.

[jolly portal]

If you could that would be very helpful!

[mellow trout]

Thank you for your patience. My teammate didn't find a specific timeout window for those requests, but agreed that is likely what is happening as we don't regularly ping readers to check their state, so we don't know a reader is unavailable until it doesn't respond to us.

[jolly portal]

Ok thank you