Navigation commit failure leaves the loading state active and causes inconsistent internal state
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- react, typescript
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- TypeScript
- Star
- 580
- Fork
- 56
- Merge trung bình
- 11 giờ 28 phút
- Pull request đã merge (30 ngày)
- 150
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của voidzero-dev/void
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
voidzero-dev/void#619 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
voidzero-dev/void#606 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
@void/react: client environment has no optimizeDeps.entries for pages, causing a dev re-optimization reload on first loadCó thể đã có người làm @0froq đã nhận hôm nay. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 66/100
voidzero-dev/void#599 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`void/log`: add `logger.child(fields)` to bind fields to every lineCó thể đã có người làm @Dazzanova đã nhận 1 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 82/100
voidzero-dev/void#596 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 56/100
voidzero-dev/void#579 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của voidzero-dev/void
Issue tương tự
-
comp/desktop desktop/shell os/windows P3 tool/file type/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
NousResearch/hermes-agent#145928 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
compiler-dom: stringifyStatic renders :disabled="0" as a present attributeCó thể đã có người làm @DaZuiZui đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
vuejs/core#16051 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 74/100
-
integration:coding-agents
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 83/100
vectorize-io/hindsight#6151 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
DogFooding
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
OpenAEV-Platform/openaev#8768 ·
Maintainer thường phản hồi trong vòng 1 ngày