Skip to content

Conversation

mansourebadian
Copy link

Problem
In the current version, the onRetry callback is executed immediately after the error occurs — before the configured retryDelay has finished.

This causes onRetry to report retry information while the next attempt hasn’t actually been sent yet.

As a result, developers cannot accurately control or log the exact “just before resend” moment, and certain cancellation logic or tests behave unexpectedly.

Solution
The handleRetry function has been updated so that:

onRetry(currentState.retryCount, error, config) is moved inside the setTimeout callback.
The premature execution before the delay is removed.
Timeout variable naming and abort listener handling are made more consistent.
With this change, onRetry is now triggered right after the delay finishes and just before sending the retry request, making the retry flow more predictable and semantically correct.

Benefits
Better alignment between “waiting” and “resending” phases.
Accurate logging, metrics tracking, and UI updates for retry events.
Fixes unintended behavior in unit tests related to onRetry.

Related discussion: issue

…eRetry

Changed handleRetry logic so that onRetry callback is no longer called immediately
before the delay starts. Instead, it now runs inside the setTimeout after the
configured retry delay has elapsed, and just before the retry request is sent.
This ensures better separation between "waiting" and "sending" phases of retry,
allowing consumers to handle cancellation or status updates accurately. Also
removed the initial onRetry invocation that happened before delay.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant