Skip to content

fix(aggregator): shell pages — a stalled/failed fragment must surface, not spin (board/today/attention) #1503

Open

Description

@dezren39

Problem (observed in source + live sizes, 2026-10-27)

The three highest-traffic pages — / (board), /today, /attention — are shells (#1444): the server returns nav + a skeleton ("Loading the board…", "Loading today…") and the real content streams in as a Datastar fragment (data-on-load="@get('/frag/…')"). The only fallback in the shell markup is a <noscript> meta-refresh to ?full=1.

There is no error or timeout path: src/render.ts / src/server.ts contain no fragment error handling at all (verified by grep — no data-on-error, no watchdog). If the fragment request fails or stalls — tailnet hiccup, server busy (full renders measured today at 2.36 MB for the board and 3.53 MB for attention), a wedged source — the page sits on its skeleton indefinitely: no message, no retry affordance, no link through to the full render. To the reader that is indistinguishable from "the dashboard doesn't load", and it is a plausible contributor to exactly that report that is not a data problem.

Design

A shell-side watchdog, no protocol change: if the fragment has not replaced the skeleton within ~10 s, the skeleton is swapped for an inline notice — the live view didn't arrive — <a href="?full=1">load the full page</a> — implemented in the shell's own inline script / Datastar error hooks. The ?full=1 server render already exists and is the no-JS path; this just gives the JS path a way to reach it when the fragment dies.

Acceptance

  • With /frag/* requests blocked, each of /, /today, /attention shows the notice with a working full-page link within the time bound.
  • Normal path unchanged: when the fragment lands, no notice ever appears.
  • ?full=1 renders are untouched.

Related: #1444 (introduced the shells), #1179 (fragment weight — the stall risk grows with it).

Activity

  1. added
    priority/normalOrdinary priority (the default)
    app/pm-stackpm-stack (Pad/Grist) in developing-today/code
    on Oct 27, 2026
  2. developing-today commented on Oct 27, 2026

    @developing-today
    Contributor
  3. added
    effort/sSmall: expected under 2 hours of work
    source/humanFiled directly by a human
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 27, 2026
  4. dezren39 commented on Oct 27, 2026

    @dezren39
    MemberAuthor

    Intake review

    Related: #1444 (shells), #1179 (fragment weight). Liveness: no merged PR adds fragment error handling — checked merged aggregator PRs through 2026-10-27 (#1434, #1330 latest); issue is live. Its ## Acceptance section is a full criteria set in substance, so no duplicate section was appended.

    Notes / risks / suggested approach: Risk: watchdog must never fire on the normal path (slow-but-live fragments on a busy server) — the time bound and the fragment-replaced check are the delicate parts. Suggested approach: shell inline script / Datastar error hooks only, no protocol change, exactly as designed; test with /frag/* blocked per page.

    🤖 Agent note · filed

    • Agent: fleet monitor (repo-fleet-monitor)
    • Session / ID: repo-fleet-monitor run 2026-10-27 14:19 CDT — intake enrichment (protocol §5)
    • Found via: monitor reconciliation
    • Task: Shell pages (/, /today, /attention) spin forever when the Datastar fragment stalls/fails; add a ~10s shell-side watchdog swapping the skeleton for a notice linking ?full=1.
    • Expectation: intake only this run — labels normalized, liveness checked, acceptance criteria in place; the fix itself routes through the normal queue/sweep path
    • Links: n/a
  5. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed on Nov 1, 2026
  6. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

    • Agent: queue worker (repo-worker-code), lane C
    • Session / ID: queue task 2603 (triage; repo-queue-worker-shift-c, 2026-11-01T04:47Z)
    • Found via: queue claim
    • Task: Triage fix(aggregator): shell pages — a stalled/failed fragment must surface, not spin (board/today/attention) #1503 against current main: verify the aggregator shell pages still have no fragment error/timeout path, then route as a scoped follow-up packet or close with evidence.
    • Expectation: effort s; done = agent-note triage verdict posted, follow-up packet enqueued if confirmed, labels synced.
    • Links: queue task 2603
  7. 4 remaining items

  8. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    work/assignedQueue worker lifecycle state
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 1, 2026
  9. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  10. added
    queue/blockedQueue or user escalation state
    status/blockedQueue or user escalation state
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 1, 2026
  11. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · blocked — packet defect

    • Agent: repo-worker-code (OpenChamber scheduled lane)
    • Session / ID: OpenCode session ses_e5e66df96e6ffe9Z0h1Lh18u82; queue task 5019
    • Defect: On freshly fetched origin/main eb226be58, server.ts:671-673 serves renderBoard(...) directly for /board; it has no shell/full ?full=1 branch. renderBoardShell() exists at render.ts:1689 but is unused; /frag/board is only a fragment endpoint. The packet requires a /board watchdog and working /board?full=1 link, so this is more than the stated watchdog-only change.
    • Needed to unblock: Correct the packet by deciding whether /board should become a shell with ?full=1 preserving the full render, or whether acceptance is limited to the active shell routes. No source edits were made.
  12. developing-today commented on Nov 3, 2026

    @developing-today
    Contributor

    agent-note:v1
    state: reviewed (coverage loop-back)
    Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 5019 (small_fix, blocked, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
    Found via: coverage loop-back 2026-11-03

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

app/pm-stackpm-stack (Pad/Grist) in developing-today/codeeffort/sSmall: expected under 2 hours of workkind/enhancementmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)queue/blockedQueue or user escalation statequeue/queuedHas a queued task in the Supabase agent queuesource/humanFiled directly by a humanstatus/blockedQueue or user escalation statetask/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions