Remove completed Issue #50 navigation abort signal task
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
@@ -1,30 +1,3 @@
|
||||
### Issue #50: HIGH - Navigation Abort Signal Timing Bug
|
||||
|
||||
**Where found**:
|
||||
- `frontend/src/providers/NavigationCancellationProvider.tsx:52-67`
|
||||
|
||||
**Why this is needed**:
|
||||
The `AbortController` is recreated inside a `useEffect` that fires after render. A request initiated synchronously during the render (before the effect runs) receives the previous cycle's signal — which may already be aborted — and is cancelled immediately instead of completing.
|
||||
|
||||
**Goal**:
|
||||
Ensure the fresh `AbortController` is available before any request is initiated on a new route.
|
||||
|
||||
**What to do**:
|
||||
1. Create the new `AbortController` synchronously (outside `useEffect`) when the pathname changes, using `useMemo` or `useRef` with a pathname-keyed guard.
|
||||
2. Only abort the old controller inside the effect to avoid aborting the new signal.
|
||||
|
||||
**Possible traps and issues**:
|
||||
- React strict mode double-invokes effects; ensure the controller is not aborted on the first invocation.
|
||||
- `useMemo` is not guaranteed to be stable; prefer `useRef` + pathname comparison.
|
||||
|
||||
**Docs changes needed**:
|
||||
- Update `frontend/src/providers/PROVIDER_ORDER.md` if the timing contract changes.
|
||||
|
||||
**Doc references**:
|
||||
- `frontend/src/providers/PROVIDER_ORDER.md`
|
||||
|
||||
---
|
||||
|
||||
### Issue #51: MEDIUM - Repository Boundary Not Type-Enforced
|
||||
|
||||
**Where found**:
|
||||
|
||||
Reference in New Issue
Block a user