keep-alive and beforeRouteLeave: pending request cancellation interoperability

Answer

The beforeRouteLeave guard runs before the component instance is unmounted, while keep-alive's activated hook fires after the cached instance is remounted. If a request is still in flight when the guard cancels it, the subsequent activated call can re‑trigger the same request unless the cancellation state is persisted outside the component instance.

Confirmed facts

• beforeRouteLeave executes before Vue destroys the component; any cleanup placed there (e.g., calling abort() on an AbortController) happens while the instance still exists.
• keep-alive preserves the existing instance; activated re‑hydrates it without re‑running beforeRouteEnter. Local refs or interceptor flags that live on the instance are lost when the instance is temporarily removed from the DOM.
• An axios interceptor flag stored on the component instance does not survive the keep‑alive deactivate/activate cycle, leading to a race where activated resets the flag and re‑issues the request.

Likely explanation

The duplication occurs because the cancellation signal (or suppression flag) is scoped to the component instance, which keep‑alive discards temporarily. When the instance is remounted, the flag is re‑initialized to its default state, allowing the pending request to be retried.

Steps to ensure a single async write

1. Create a shared cancellation object (e.g., an AbortController) or a suppression flag in a global store such as Pinia or a simple singleton module.
2. In beforeRouteLeave, call abort() on the shared controller and set the suppression flag to true.
3. In activated, before launching the request, check the shared controller’s signal.aborted flag (or the suppression flag). If abort is true or the flag is set, skip the request or wait for the abort to settle.
4. After the request settles (success or error), reset the suppression flag to false in the store so a future navigation can allow a new request.

Verification

Add console logs in beforeRouteLeave, deactivated, and activated to confirm the order: leave → deactivated → (keep‑alive cache) → activated. Then verify that calling abort() on the shared controller prevents the request logged in activated. Finally, watch the store’s suppression flag to ensure it persists across the cycle and resets only after the request finishes.

Missing diagnostic detail

If you are already using a global store for the cancellation state, confirm whether the store is re‑initialized on page reload; otherwise the pattern above is sufficient. If not, please specify whether you can introduce a Pinia/singleton store, as this determines if the shared controller approach is viable.