According to the documentation retry uses a "exponential fallback schedule", but I'm seeing that the delay between retries stays at always 1000ms. The reason is that if CouchDB returns a 200 with a null body (as it does for me), it's considered what the debug message calls a 'Good response', which restarts the retry delay. And because it's not really a good response, it retries anyway (as it should). This happens whenever I follow a view which does not exist.
If I change it so that the delay is not reset on an empty body it just retries continuously without waiting until it reaches the maximum.
According to the documentation
retryuses a "exponential fallback schedule", but I'm seeing that the delay between retries stays at always 1000ms. The reason is that if CouchDB returns a 200 with a null body (as it does for me), it's considered what the debug message calls a 'Good response', which restarts the retry delay. And because it's not really a good response, it retries anyway (as it should). This happens whenever I follow a view which does not exist.If I change it so that the delay is not reset on an empty body it just retries continuously without waiting until it reaches the maximum.
Thoughts?