Uh oh!
There was an error while loading. Please reload this page.
fix: recover watch stream on more error types - #9995
Conversation
tritone
left a comment
There was a problem hiding this comment.
Just noting that several of these errors are noted as non-retryable under https://aip.dev/194 , however I don't have enough context specific to firestore and this client to understand whether this is problematic or not.
BenWhitehead
commented
Dec 18, 2019
@schmidt-sebastian Can you take a look at the list of error codes here and weigh in if they are okay to retry or not? |
crwilcox
commented
Dec 18, 2019
I should note in theory, |
schmidt-sebastian
commented
Dec 19, 2019
Can we match Node? The list is even more permissive: https://github.com/googleapis/nodejs-firestore/blob/25472e11a0e1a4a5e1931b1652d125f9c8cabf11/dev/src/watch.ts#L817 |
crwilcox
commented
Dec 20, 2019
@jadekler voiced concerns about many of the retry codes in Go that I copied. I also found that this didn't fully stop the issue. It is possible I could match node. I have a debug session running and am waiting for a failure so I can dig into what went on. |
crwilcox
commented
Dec 23, 2019
I left this run for a few days. I think if we just retry |
jeanbza
commented
Dec 23, 2019
Did you figure out whether RST_STREAM was being returned as an INTERNAL error or not? If so, the change you propose makes sense to me.
INTERNAL in addition to UNAVAILABLE, or just by itself? (UNAVAILABLE should always be retried) |
schmidt-sebastian
commented
Dec 26, 2019
I would prefer if we used the same retry configuration everywhere, and the Node SDK has the configuration that is most battle-tested. We should try to retry every Watch request unless we know beforehand that a retry will not help (e.g. "PERMISSION_DENIED"). If we don't do this, our users will, and they will do so without backoff. |
crwilcox
commented
Dec 26, 2019
@jadekler I haven't gotten an answer on that yet, but discussion is ongoing at b/144734355. I think for now @schmidt-sebastian has a reasonable point. Customer of watch are determined to keep it running, likely to the point of personally retrying any of the codes. If we retry most all of them, but with sensible timeouts, that is likely better than leaving it to chance. I will modify this PR to match Node.js |
crwilcox
commented
Jan 2, 2020
Merging this. We have further discussion internally on whether RST_STREAM should occur with the error type we are seeing (INTERNAL), but this ought to resolve the issues for users currently. We can always soften later if this becomes unecessary. |
* fix: Recover watch stream on more error types. RST_STREAM for example is INTERNAL * fix: match recovered stream exceptions to node.js implementation, https://github.com/googleapis/nodejs-firestore/blob/25472e11a0e1a4a5e1931b1652d125f9c8cabf11/dev/src/watch.ts\#L817
Watch Retry is more permissive in Go. This PR replicates that in Python.
Fixes#9890 and b/144734355