Navigation commit failure leaves the loading state active and causes inconsistent internal state
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- react, typescript
Direzione di ricerca
Read packages/react/src/runtime/pages-client.ts around finishNavigation() and packages/void/src/pages/navigation-engine.ts around makeCommit(). Trace how pending visits, reducer failure actions, internal committed state, and scrollRestoration.writeHistory() interact when history writing throws. Reproduce with the provided component and verify the error propagates, navigation returns to idle, state stays consistent, and an older failure cannot reset a newer navigation.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
When history.pushState() or history.replaceState() throws during navigation, router.visit() rejects, but useNavigation().state remains loading.
Additionally, Void updates its internal committed state before writing browser history. If the history update fails, the browser URL and internal navigation state become inconsistent.
Reproduction
- Configure a valid Void page at
/b. - Render the following React component:
import { useNavigation, useRouter } from '@void/react';
export default function Example() {
const router = useRouter();
const navigation = useNavigation();
async function navigate() {
const original = history.pushState;
history.pushState = () => {
throw new DOMException(
'History update failed',
'SecurityError',
);
};
try {
await router.visit('/b');
} catch {
// Inspect the navigation state after failure.
} finally {
history.pushState = original;
}
}
return (
<>
<p>Navigation: {navigation.state}</p>
<button onClick={navigate}>Navigate</button>
</>
);
}
- Click the button and inspect the navigation state and browser URL after the failed navigation.
Actual behavior
router.visit()rejects.useNavigation().stateremainsloading.- The browser URL remains unchanged.
- Void's internal current URL and committed resource have already been updated.
- Restoring normal history behavior and navigating to another page clears the stuck navigation state.
Expected behavior
A failed history update should terminate the navigation cleanly and preserve state consistency.
- The navigation state returns to
idle. - The original error propagates to the
router.visit()caller. - The browser URL, rendered page, and internal navigation state remain consistent.
- Subsequent navigations continue to work normally.
Root cause
In packages/react/src/runtime/pages-client.ts, finishNavigation() rejects the visit promise when resource.commit() fails, but does not clear the active pending navigation or dispatch a failure action.
resource.commit()
.then((committed) => {
// Successful navigation cleanup.
})
.catch((error) => {
const visitSettler = pendingVisitSettlers.get(resource.id);
if (visitSettler) {
pendingVisitSettlers.delete(resource.id);
visitSettler.reject(error);
}
});
The reducer already supports fail and abandon actions that reset the navigation state, but neither is dispatched in this failure path.
Additionally, in packages/void/src/pages/navigation-engine.ts, makeCommit() modifies internal navigation state before updating browser history.
_urlNavigationId = resourceId;
// Update committed resource and deferred registry ownership.
applyClientHead(result.pageData.head as HeadDescriptor | undefined);
_currentFetchUrl = commitTarget.fetchUrl;
if (!options._popstate) {
const historyUrl = commitTarget.fetchUrl + commitTarget.hash;
scrollRestoration.writeHistory(historyUrl, !!options.replace);
}
If scrollRestoration.writeHistory() throws, the earlier internal state mutations are not rolled back, leaving the commit partially applied.
Suggested fix
- Ensure the React adapter clears the active pending navigation and dispatches the appropriate failure or rollback action when
resource.commit()rejects. - Make
makeCommit()failure-safe so that a failed history update cannot leave internal committed state inconsistent with browser history. - Ensure cleanup for a failed navigation does not overwrite or reset a newer navigation.
- Preserve existing resource lifecycle management, deferred registry ownership, and navigation ordering guarantees.
Acceptance criteria
- A failed
history.pushState()orhistory.replaceState()does not leave navigation inloadingorsubmitting. router.visit()rejects with the original error.- The browser URL, rendered page, and internal navigation state remain consistent after failure.
- Subsequent navigations work normally.
- Cleanup from an older failed navigation does not modify the state of a newer navigation.
Related issues
- #506 — preserveState prevents the destination URL from being committed (Closed)
- #507 — An older navigation can overwrite the URL after a newer navigation commits (Closed)
- #527 — Pages: actions commit the
?actionNameURL to history (Open)
Unlike these issues, this report concerns error handling and state consistency when a browser history update throws during navigation commit.
- Lingua principale
- TypeScript
- Stelle
- 580
- Fork
- 56
- Merge medio
- 8h 36m
- PR unite (30g)
- 110
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di voidzero-dev/void
-
Static Cloudflare deploy ignores `cloudflare.assets.html_handling`Forse già presa @0froq l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
voidzero-dev/void#580 ·
I maintainer di solito rispondono entro 1 giorno
-
`void/log` serializes `Error` fields as `{}`, losing message and stackForse già presa @RaphaelFakhri l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
voidzero-dev/void#577 ·
I maintainer di solito rispondono entro 1 giorno
-
vp build / void deploy exit 0 when a page fails to prerender, and the page is silently missingAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
voidzero-dev/void#576 ·
I maintainer di solito rispondono entro 1 giorno
-
Dev: `better-auth/client/plugins` fails to resolve when auth is enabled (the `better-auth/client` alias matches it as a prefix)Forse già presa @MaxtuneLee l’ha presa 2 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
voidzero-dev/void#565 ·
I maintainer di solito rispondono entro 1 giorno
-
prepareDeployArtifact omits worker.vars that the CLI managed deploy includesForse già presa @dvkam l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
voidzero-dev/void#529 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di voidzero-dev/void
Issue simili
-
Native Web
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 80/100
digitalfabrik/integreat-app#4517 ·
I maintainer di solito rispondono entro 2 giorni
-
TLS guide repeats certs/ in the certificate directoryForse già presa @maheshrijal l’ha presa oggi. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
prometheus/docs#3156 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
medusajs/dtc-starter#90 ·
I maintainer di solito rispondono entro 1 giorno
-
usability
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
inmanta/web-console#7632 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
zaidmukaddam/scira#261 ·