Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Flaky E2E: saved-search save→navigate race (saved-search.spec.ts:212, :422)

Aperta
  • Qualcosa non va?
#2,644 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
playwright, react, typescript
Ambito
frontend, testing-qa

Direzione di ricerca

Esegui make dev-e2e FILE=saved-search ARGS="--repeat-each=3" e analizza i test che falliscono alle righe 212 e 422 in packages/app/tests/e2e/features/search/saved-search.spec.ts. Segui il ramo di creazione in DBSearchPage.tsx attorno a onSubmit e useCreateSavedSearch in packages/app/src/savedSearch.ts, concentrandoti sulla navigazione, sugli aggiornamenti dell’URL e sull’invalidazione delle query. Il lavoro è completato quando il salvataggio raggiunge in modo affidabile /search/<id> senza retry durante esecuzioni ripetute in parallelo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Two E2E tests in packages/app/tests/e2e/features/search/saved-search.spec.ts are intermittently flaky under parallel load. Both fail at the save → navigate step: after clicking Save in the saved-search modal, the app does not navigate to the /search/<id> permalink, so SavedSearchModalComponent.saveSearchAndWaitForNavigation() times out on page.waitForURL(/\/search\/[a-f0-9]+/).

Affected tests:

  • saved-search.spec.ts:212 — should load saved search when navigating from another page
  • saved-search.spec.ts:422 — should update ORDER BY when switching sources multiple times

Observed ~1-in-3 under --repeat-each=3 across the full saved-search spec (9 workers, dev-mode server). Both recover on Playwright retry, so they show as flaky.

Evidence (this is an app race, not a test-helper issue)

At failure the page is on the plain, unsaved search view, not the saved-search detail page:

  • WHERE / ORDER BY / SELECT config is all correct and results are loaded.
  • The action bar shows "Save" (not "Update"), and there is no saved-search name title → the search was never persisted into the detail view.
  • No error toast, and the API logs show no POST /saved-search error → the save request itself is not erroring.
  • The modal has closed and the URL is still /search?...&orderBy=... (the pre-save searched URL), never /search/<id>.

So the create request succeeds but the client-side router.push('/search/${savedSearch.id}${window.location.search}') in DBSearchPage.tsx (onSubmit, ~line 546) is effectively lost/clobbered under load — the navigation appears to race with the search-config URL update and/or the ['saved-search'] query invalidation (useCreateSavedSearch onSuccess in packages/app/src/savedSearch.ts).

Discriminator: tests 56 and 293 use the same createSavedSearch + router.push path and pass solidly (3/3, no retries) after an unrelated fix. 212/422 differ in that they perform an explicit search-then-save with a custom WHERE/ORDER BY, which is what appears to open the race window.

Ruled out

  • Not a lost submit click — a guarded submit-retry in the test helper did not help (the modal does close; re-clicking is a no-op). Reverted.
  • Not a duplicate-name / shared-DB artifact — other fixed-name saved-search tests create the same name 3× and pass.
  • Not an autocomplete-overlay or CodeMirror keystroke-drop flake (those were the separately-fixed pie-chart and setCustomSELECT issues).

Suggested investigation

  • In DBSearchPage.tsx onSubmit (create branch), confirm whether a concurrent search-config URL update or a redirect-on-"saved-search-not-found" (while ['saved-search'] is still refetching after invalidation) overrides the router.push('/search/<id>').
  • Consider navigating using the freshly returned savedSearch object / seeding the query cache before router.push, or making the saved-search detail route tolerant of the item not yet being in cache instead of falling back to /search.

Repro

make dev-e2e FILE=saved-search ARGS="--repeat-each=3"

Failure signature:

TimeoutError: page.waitForURL: Timeout 15000ms exceeded.
  navigated to "http://localhost:.../search?source=...&orderBy=ServiceName%20ASC&..."
  at components/SavedSearchModalComponent.ts (saveSearchAndWaitForNavigation)
Lingua principale
TypeScript
Stelle
10k
Fork
501
Merge medio
2g 3h
PR unite (30g)
152

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di hyperdxio/hyperdx

Tutte le issue di hyperdxio/hyperdx

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.