Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 Stale closure causes fetcher.state check to always read 'idle'
By removing
fetcherfrom theuseCallbackdependency array, thefetchIncidentscallback captures thefetcherobject from the initial render. Since Remix'suseFetcherreturns a new object on each render, the capturedfetcher.statewill always be"idle"(the initial state), making the guardif (fetcher.state === "idle")ineffective.Click to expand
How the bug is triggered
The callback is created once with an empty dependency array:
When the interval fires every 60 seconds,
fetcher.statein the closure always reads"idle"regardless of whether a request is currently in progress.Actual vs Expected
fetcher.load()if a request is already in progressfetcher.statealways reads as"idle", sofetcher.load()is called even if a request is pendingImpact
This could cause unnecessary duplicate network requests if the previous request hasn't completed within 60 seconds. In practice, the impact is limited because:
fetcher.loadcancels previous pending requestsA proper fix would use a ref to track the fetcher state or use
fetcher.statedirectly outside the callback.Recommendation: Use a ref to track loading state, or check
fetcher.stateoutside the callback and pass it as a parameter. Alternative: Sincefetcher.loadis stable and cancels previous requests, the guard could be removed entirely if duplicate requests are acceptable.Was this helpful? React with 👍 or 👎 to provide feedback.