Initially the custom retry handler was put in place to give the client true freedom of handling retries. I quickly saw this comes at a cost of making the simple mistake (which I had done !) of infinitely retrying.
Now there are two approaches to this.
1) Respect the underlying spirit of custom retries and having the client handle the retries (which is what this PR is proposing by passing back the retriesCount).
2) Limiting it on the library and not the client level with a conditional.
I have no belief that one is greater than the other but would like to respect the spirit of the initial PR.
So whats the point of this PR at all. To avoid hardcoding and passing values. This is simply cleaner.
Initially the custom retry handler was put in place to give the client true freedom of handling retries. I quickly saw this comes at a cost of making the simple mistake (which I had done !) of infinitely retrying.
Now there are two approaches to this. 1) Respect the underlying spirit of custom retries and having the client handle the retries (which is what this PR is proposing by passing back the retriesCount). 2) Limiting it on the library and not the client level with a conditional.
I have no belief that one is greater than the other but would like to respect the spirit of the initial PR.
So whats the point of this PR at all. To avoid hardcoding and passing values. This is simply cleaner.
Checklist
npm run testandnpm run benchmark