test(frontend): useAuth's expiry test waits for the user, not the element (main is red) #785

Merged

claude-bot merged 3 commits from fix/useauth-test-race into main 2026-09-23 20:56:25 +00:00

Conversation 0 Commits 3 Files changed 2 +33 -4

claude-bot commented 2026-09-23 18:44:17 +00:00

Collaborator

Copy link

Main is red after #783 merged: run #10357, useAuth.test.jsx, "Expected … Test User / Received: anonymous". Nothing in #783 touched auth, and the same tree had passed on #783's own PR run and inside #782's.

Cause

AuthProvider renders its children immediately, so the test's probe exists reading "anonymous" until /api/me answers. The test did:

expect(await screen.findByTestId("home-user")).toHaveTextContent("Test User");

findByTestId resolves as soon as the element exists, and then the text is asserted, which on a loaded runner is a moment before the user arrives. The test has always been a race that usually won.

Fix

It now waits for the name itself:

await waitFor(() => {
  expect(screen.getByTestId("home-user")).toHaveTextContent("Test User");
});

Five runs on a single CPU: 2/2 each.

The pattern

This is the third race of the same shape today. Each time, the test waits for the first thing on the page and asserts something that arrives later:

1. J6's axe scan waited for the session's first request, and the failing elements came in a second one (#770).
2. The Contents test waited for "This week" (from the URL) and asserted the GM-only Settings entry, which waits for my_role (23c82b4).
3. This one.

expect(await findBy…(…)).toHaveTextContent(…) appears in 50 places across the suite. Most are safe: where the element only appears once its data has arrived, existing is being ready. It races only when a placeholder with the same selector renders first and its content changes later. I haven't rewritten them blind. Worth a separate audit that classifies each site.

🤖 Generated with Claude Code

**Main is red** after #783 merged: run #10357, `useAuth.test.jsx`, *"Expected … Test User / Received: anonymous"*. Nothing in #783 touched auth, and the same tree had passed on #783's own PR run and inside #782's. ## Cause `AuthProvider` renders its children immediately, so the test's probe exists reading **"anonymous"** until `/api/me` answers. The test did: ```js expect(await screen.findByTestId("home-user")).toHaveTextContent("Test User"); ``` `findByTestId` resolves as soon as the element **exists**, and then the text is asserted, which on a loaded runner is a moment before the user arrives. The test has always been a race that usually won. ## Fix It now waits for the name itself: ```js await waitFor(() => { expect(screen.getByTestId("home-user")).toHaveTextContent("Test User"); }); ``` Five runs on a single CPU: 2/2 each. ## The pattern This is the **third race of the same shape today**. Each time, the test waits for the first thing on the page and asserts something that arrives later: 1. J6's axe scan waited for the session's first request, and the failing elements came in a second one (#770). 2. The Contents test waited for "This week" (from the URL) and asserted the GM-only Settings entry, which waits for `my_role` (23c82b4). 3. This one. `expect(await findBy…(…)).toHaveTextContent(…)` appears in **50** places across the suite. Most are safe: where the element only appears once its data has arrived, existing *is* being ready. It races only when a placeholder with the same selector renders first and its content changes later. I haven't rewritten them blind. Worth a separate audit that classifies each site. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-09-23 18:44:18 +00:00

test(frontend): useAuth's expiry test waits for the user, not the element ... 8e7b0b4da1

Main went red after #783 merged (run #10357): `useAuth.test.jsx` expected
"Test User" and read "anonymous". Nothing in #783 touched auth; the same tree
had passed on two PR runs.

`AuthProvider` renders its children at once, so the probe exists reading
"anonymous" until /api/me answers. `findByTestId` resolves on existence, and
the text was then asserted a moment too early on a loaded runner. It has
always been a race that usually won.

Now it waits for the name itself. Five runs on a single CPU: 2/2 each.

This is the third race of the same shape today — wait for the first thing
on the page, assert something that arrives later — after J6's axe scan and
the Contents' Settings assertion.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

rbrooks added 2 commits 2026-09-23 19:30:50 +00:00

Merge remote-tracking branch 'origin/main' into fix/useauth-test-race 7c6f0eed36

test(frontend): the crumb tests wait for the campaign's name (#729) ... 53c8cd9ab0

Main went red again after #782 merged (run #10371), in a different test:
AppFrame.test.jsx › "gives the sessions list a page of its own", line 295.

Same shape as the useAuth fix in this PR and as 23c82b4. The test waited for
the current Contents entry — worked out from the address, there on first
paint — then read the breadcrumb's campaign link, whose name arrives with the
campaign list a request later.

Rather than fix it one red run at a time, every test in the file was checked
for an assertion on campaign data made after a wait on something
address-derived. Two race:

- "gives the sessions list a page of its own" (the one that failed)
- "marks the wiki current for everything under it" — identical shape, and
  had simply not lost yet

Both now wait through `crumbToCampaign()`, which returns the crumb once its
campaign link is there. The others were checked and are sound: "Running it",
the settings-sections tests and "keeps the sections out" all wait on a
role-gated element before asserting, so the role has arrived; the new-session,
new-campaign and edit-session tests assert only address-derived things.

Three runs of both files on a single CPU: 51/51 each.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

claude-bot merged commit 580d969c83 into main 2026-09-23 20:56:25 +00:00

claude-bot referenced this pull request from a commit 2026-09-23 20:56:27 +00:00

Merge PR #785: three timing races in the frontend tests — useAuth and the crumbs wait for the data they assert

claude-bot referenced this pull request 2026-09-23 20:56:52 +00:00

Build lane 3: the campaign core and Settings (CAMP-1 to CAMP-17, SH-7) #729

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

backend

Issue related to the backend

  

bot

Issue related to the bot

  

bug

Something is not working

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

frontend

Issue related to the frontend

  

help wanted

Need some help

  

invalid

Something is wrong

  

question

More information is needed

  

recording

Issue related to the recording system

  

security

Security hardening / vulnerability work

  

wontfix

This won't be fixed

No labels

backend

bot

bug

duplicate

enhancement

frontend

help wanted

invalid

question

recording

security

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

rbrooks/Quest-Board!785

No description provided.