Anonymous desktop /waves never resolves: skeleton cards forever + 'No waves to display'

[brookr]

Observed

On production (2026-07-05, ~23:45 UTC), anonymous desktop /waves (1440x900, Chromium) renders the shell and the 'Latest From Profile Waves' heading, but the masonry stays in skeleton placeholders indefinitely (>8s, no settle) and the left wave rail shows 'No waves to display'. Logged-in sessions render the same page fine.

How this surfaced

The 6529bot responsiveness lane flagged web-desktop /waves as a blank capture (screenshotBlankLike=true, nonWhiteRatio=1, luminanceStdDev=2.61, visibleTextLength=33) on two consecutive runs against PR #3123 — a test-only PR that cannot affect rendering. Reproduced independently against production with plain Playwright: 0 a[href^="/waves/"] links, 187 chars of visible text. A local dev stack (working local API) renders 36 wave links on the same code, pointing at the anonymous data-fetch path rather than the component tree.

Impact

Anonymous desktop visitors get a permanent loading state on the waves discovery surface — no content, no empty-state, no sign-in prompt. Also makes the responsiveness lane's blank-detection fire on unrelated PRs.

Notes

• Electron and web-mobile contexts render /waves content in the same responsiveness runs, so it is desktop-web + anonymous specific.
• Evidence: responsiveness artifacts on PR Add Win 8-sequence latch regression pack to the staging E2E battery #3123 (runs sMMcvLuVJJlcwf1Ym3dsOChF-ZWc17vB and G25iwzEQ0Ni4G-K7ZDxFtke1p8llau-K), plus independent Playwright repro described above.

🤖 Generated with Claude Code