Navigation commit failure leaves the loading state active and causes inconsistent internal state

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.

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

1. Configure a valid Void page at /b.
2. 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>
    </>
  );
}

3. Click the button and inspect the navigation state and browser URL after the failed navigation.

Actual behavior

• router.visit() rejects.
• useNavigation().state remains loading.
• 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() or history.replaceState() does not leave navigation in loading or submitting.
• 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 ?actionName URL to history (Open)

Unlike these issues, this report concerns error handling and state consistency when a browser history update throws during navigation commit.