Frontend: DashboardPage lookup has no AbortController — in-flight fetch not cancelled on rapid re-lookups

[k-deejah]

Difficulty: Advanced

Problem

1. DashboardPage.lookup() starts a fetch but never cancels it if the user changes the public key and searches again
frontend/src/pages/DashboardPage.tsx lines 22–38: the lookup function is an inline async that sets loading = true, fires fetch(), and updates state on response. If the user types a new key and clicks Lookup again while the first fetch is still in-flight, two fetches run concurrently. Whichever resolves last wins — the results can be from the first (stale) request.

2. Unlike useQueues which uses a cancelled flag, DashboardPage has no cleanup
frontend/src/hooks/useQueues.ts correctly uses let cancelled = false and checks it before calling setQueues(). The dashboard's inline lookup function has no equivalent guard — it will call setRecords(data) even after the component unmounts or after a second lookup has been initiated.

3. lookup is recreated on every render but never wrapped in useCallback
The function is defined inside the component body without useCallback, creating a new function reference on every render. While this has minimal direct performance impact, it prevents correct memoization if lookup is ever passed to a child component.

Impact: Race conditions between concurrent lookup requests produce flickering, stale results. If the component unmounts while a lookup is in-flight (e.g., user navigates away), React logs a "Can't perform state update on unmounted component" warning and may cause memory leaks.

Proposed Solution

• Add an AbortController to lookup(): create a new controller on each call, cancel the previous one, pass signal to fetch().
• Track the current controller in a useRef so it persists across renders.
• Wrap lookup in useCallback with [publicKey] dependency.
• Add a component unmount cleanup to abort any in-flight request.

Acceptance Criteria

• lookup() uses AbortController to cancel previous in-flight requests
• Previous fetch is aborted when a new lookup is started
• fetch receives { signal: controller.signal }
• Aborted request does not update component state
• Unmount cleanup aborts any in-flight request
• lookup wrapped in useCallback([publicKey])
• No TypeScript errors introduced

Contributor Note

If assigned, your PR must show a test (in the future frontend test suite) that demonstrates the race condition is resolved, and explain the difference between the cancelled flag pattern used in useQueues and the AbortController approach.

[Chigybillionz]

Hi, I’ve reviewed this issue and I’m confident I can fix it. I’d like to take it on.

[waterWang]

Submitted PR #218 that fixes this issue — adds AbortController-based cancellation, covers the unmount race, and wraps lookup in useCallback.

PR: #218

[Godfrey-Delight]

I'd like to work on this issue. My plan is to add a useRef<AbortController | null> in DashboardPage.tsx to hold the current in-flight request's controller, aborting the previous controller (if one exists) and creating a new one on each lookup() call, then passing { signal: controller.signal } to fetch(); I'll wrap lookup in useCallback with [publicKey] as its dependency, and add a useEffect cleanup that aborts any in-flight request on unmount, with the fetch's .catch() checking for AbortError and returning early so aborted requests never touch state. On the difference the contributor note asks for: the cancelled flag in useQueues is a soft guard — the underlying request still runs to completion and consumes network/server resources, it just discards the result on arrival — whereas AbortController is a hard cancellation that actually terminates the in-flight fetch at the network layer, so a superseded request stops consuming bandwidth and the server can stop processing it if it respects the signal, which is the better fit here since lookups can be triggered in rapid succession with no reason to let stale requests keep running. I'll also add a test demonstrating that firing two lookup() calls back-to-back results in exactly one setRecords call using the second request's data, with the first request resolving as aborted and never updating state.

[grantfox-oss]

🦊 GrantFox — @Godfrey-Delight has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #203)
2. Your PR will be reviewed by the Stellar-Deejah maintainers

Good luck! Track your progress on GrantFox.