Skip to main content
← Back to list
01Issue
BugShippedSwamp Club
Assigneeskeeb

Relationships

#908 Leaderboard profile popover stuck on skeleton loader on second open

Opened by vcjdeboer · 7/1/2026· Shipped 7/2/2026

What

The new "click an operative name → profile overview" popover on the swamp.club leaderboard loads correctly the first time, but on the second open it renders only the skeleton placeholder and never populates with the profile data.

Steps to reproduce

  1. Open the leaderboard (e.g. ALL-TIME view).
  2. Click an operative name → overview card loads fine (avatar, tier, points, badges, "VIEW FULL PROFILE"). ✅
  3. Dismiss the card, then click the same (or another) name a second time → the card appears but stays on the loading skeleton (gray placeholder bars) indefinitely. ❌

Expected

The popover repopulates with profile content on every open.

Actual

On the second and subsequent opens, the skeleton loader persists forever; the profile data never renders.

Environment

  • swamp.club web leaderboard (the profile-overview popover feature announced in SWMP club chat, 2026-07-01)
  • macOS (Darwin 25.2)

Hypothesis (optional)

Looks like a cached / in-flight fetch not being re-triggered on reopen, or a settled-empty/rejected promise being reused so the skeleton never resolves. Screenshots of both the working first-open and the stuck second-open states are available.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPEDTRIAGE+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/2/2026, 12:49:11 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
keeb assigned keeb7/1/2026, 8:35:54 PM
Editable. Press Enter to edit.

keeb commented 7/1/2026, 8:35:46 PM

Thanks for the report @vcjdeboer - I can't reproduce. What is the browser you are using?

vcjdeboer commented 7/1/2026, 8:55:57 PM

both chrome and safari, i have screenshots if needed

vcjdeboer commented 7/1/2026, 9:29:19 PM

here is a more extensive look at it with claude and chrome devtools: --- Root-cause investigation — narrowed to re-selecting the currently-open operative

Summary: Re-clicking the operative whose card is already open reverts the card to its loading skeleton and never re-fetches, so it hangs empty. The bug is isolated to re-selecting the same operative — every other path works.

Reproduction

  1. Click an operative name → brief skeleton → card renders with data. ✅
  2. While that card is open, click the same name again → card reverts to the skeleton and stays there indefinitely. ❌

Differential (what works vs. what fails)

┌─────────────────────────────────────────────┬───────────────────────────────┐ │ Action │ Result │ ├─────────────────────────────────────────────┼───────────────────────────────┤ │ Click a name (nothing open) │ ✅ skeleton → card loads │ ├─────────────────────────────────────────────┼───────────────────────────────┤ │ Click a different name while a card is open │ ✅ new card loads │ ├─────────────────────────────────────────────┼───────────────────────────────┤ │ Click the same already-open name again │ ❌ reverts to skeleton, stuck │ ├─────────────────────────────────────────────┼───────────────────────────────┤ │ Click outside the card │ ✅ closes normally │ └─────────────────────────────────────────────┴───────────────────────────────┘

So the failure is isolated to re-selecting the currently-selected operative.

Network evidence (devtools → Fetch/XHR)

  • First open of an operative → a card request fires: 200, ~0.5 kB, initiator fresh-island__OperativeCard.
  • Re-clicking the same open operative → no card request is issued at all (no new row in the network log).
  • No console error on the stuck state.

Diagnosis (hypothesis) The click handler unconditionally resets the card to its loading state (clears data → skeleton), but the fetch is gated on the selected-operative id changing. Re-clicking the same operative leaves that id unchanged, so:

  • the "reset to loading" runs → skeleton, but
  • the fetch effect keyed on [selectedId] doesn't re-run (deps unchanged) → no fetch → stranded skeleton.

The differential confirms it: a different name changes the id → effect re-runs → loads fine; the same name doesn't. This rules out a global fetch-once flag (that would break different names too) and rules out a data/response problem (the first fetch is a clean 200 with a body). A close cousin would be a cache-hit branch that clears the view then early-returns without re-applying the cached data (if (cache.has(id)) return; forgetting to re-render it) — same symptom.

Suggested fix directions (any one)

  • Make a same-id re-click a no-op (or a toggle/close) instead of a state reset.
  • Don't clear the card to skeleton unless a fetch will actually follow — i.e. couple the reset and the fetch.
  • On click, if data for that id is already in hand, re-render it directly rather than clearing and waiting on an effect that won't fire.

Environment: reproduces in both Safari and Chrome on macOS.

keeb commented 7/2/2026, 12:49:21 AM

Thanks @vcjdeboer for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.