Repository navigation
Conversation
The dictionary search specs assert only on the client side navigation, but landing on a /dictionary/[lang]/[word] route makes the server render it, and that calls the provider chain directly with no HTTP route to intercept. So router.push settles only once a real upstream answers, which can take well over the 5s default in a sandboxed CI-like environment and fails the assertion even though the feature works. @LiVe specs are never run in CI, so tagging these would drop the navigation coverage entirely. Instead give the four specs that land on an entry route a 20s window, which absorbs the upstream latency while keeping them in the default run.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Two specs in
e2e/dictionary.spec.tsfailed consistently in a sandboxed CI-like environment:search > goes to the entry for the word and language chosensearch > submits on enter, without reaching for the buttonBoth fill the word field on
/dictionary, submit, and assertexpect(page).toHaveURL(/\/dictionary\/en\/<word>$/)within Playwright's default 5s timeout. The failure was alwaysReceived string: http://127.0.0.1:3123/dictionary— the client-siderouter.pushinDictionarySearchhad not settled when the assertion timed out.Root cause: the target route
apps/web/src/app/dictionary/[lang]/[word]/page.tsxis a Server Component that calls the dictionary provider chain directly (no mockable/api/dictionary/...route to intercept). A client-side navigation there triggers a real, live, unmocked upstream fetch, and the App Router only updates the URL once the RSC payload resolves. When upstream is slow, that legitimately exceeds 5s. This is a test-design gap, not a product bug — the feature works (verified manually and by provider-chain unit tests).Fix
@livespecs are never executed in CI (ci.ymlrunsnpm run e2eonly; there is noe2e:livejob), so tagging these@livewould drop the navigation coverage from CI entirely. Instead, the four specs that land on an entry route now get a 20stoHaveURLwindow via a sharedENTRY_NAVconstant, with a comment explaining why. This absorbs upstream latency while keeping the specs in the default run.The two extra specs (
percent encodes a non Latin word into the URL,carries the suggestion's own language) were latent flakes with the identical cause — a suggestion-button click alsorouter.pushes to an entry route. Runs showed them taking up to ~21s.Verification
npm run e2e -- e2e/dictionary.spec.ts --repeat-each=3, run multiple times. All entry-navigation specs pass every repeat; observed durations up to ~21s confirm the widened window is what absorbs the real upstream latency.