Repository navigation
useSmartPolling's backoff only updates currentIntervalRef — the running setInterval never slows down, yet isBackingOff flips isLive to false #569
Description
Problem
When the data is unchanged unchangedThreshold times in a row, useSmartPolling computes a longer interval:
const newInterval = Math.min(currentIntervalRef.current * backoffMultiplier, maxBackoff);
if (newInterval > currentIntervalRef.current) {
currentIntervalRef.current = newInterval;
dispatch({ type: 'START_BACKOFF' });
}But the interval is only ever created with setInterval(fetchData, currentIntervalRef.current): at mount, and again when the tab becomes visible. Changing currentIntervalRef.current afterwards has no effect on the running timer. setInterval captured the delay when it was created. The same is true in reverse: refetch() and a detected change reset the ref back to interval, but the timer isn't rescheduled.
Impact
- The documented goal of backing off to 30s (
maxBackoff: 30000inuseBountyStatus) to reduce load on a quiet bounty never happens. Requests keep going out every 5s (BountyStatus) or every 2s (ClaimButton) for as long as the page is open. isBackingOffstill becomestrue, anduseBountyStatuscomputesisLive: isPolling && !isBackingOff. SoBountyStatusstops showing the "live" indicator while the hook is in fact still polling at full speed. The UI reports the opposite of what's actually happening.
Suggested fix
Reschedule whenever the effective interval changes:
- use a self-scheduling
setTimeoutchain that readscurrentIntervalRef.currenteach time, - or
clearIntervalplus a newsetIntervalinside the backoff and reset branches.
Add a fake-timer test: with an unchanged fetchFn, after the threshold the gap between calls grows, up to maxBackoff, and it resets after a change or refetch().
Related: #46, #359. This is independent of the "polling stops after the first re-render" problem. Even with that fixed, backoff still wouldn't apply.
Activity
Biglamar commentedon Sep 27, 2026
@Biglamar has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @Biglamar to this issue.
shychips commentedon Sep 27, 2026
@shychips has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @shychips to this issue.
Temibell commentedon Sep 27, 2026
@Temibell has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @Temibell to this issue.
Teejay2696 commentedon Sep 27, 2026
@Teejay2696 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @Teejay2696 to this issue.
drips-wave commentedon Sep 27, 2026
Congratulations, @Biglamar! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.
🧑💻 @Biglamar: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.
Warning
When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.
🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.
🌊 Happy Wave 🌊
fix(hooks): reschedule active timer when polling backoff applies (Mer…
fix(hooks): reschedule active timer when polling backoff applies (Mer…
fix: resolve issue MergeFi#569