Repository navigation
Dashboard chart widget empty on first mount (pie & bar): data present, repaints on reload — first screen of every AI-built app #5451
Description
Symptom (P2, recurring): dashboard chart widget renders EMPTY on first mount — data is fine, a refresh paints it
2026-08-21 live repro on the cloud local rig (objectui fd227eae1, console built from workspace): open an AI-built dashboard (客户管理首页仪表盘, one pie widget bound to a dataset with 3 categories / 12 rows). First navigation into the dashboard renders the widget card with its title and an EMPTY chart area (no slices, no axes, no empty-state message). Press F5 → the pie renders correctly (3 slices).
The same behavior was observed on 2026-08-13 with a bar widget (no bars on mount, data confirmed present via the data API, recovers on re-render) — so it is not chart-type-specific and has survived at least a week of main.
Why it matters
This is the FIRST screen an AI-build user sees after publishing ("首页仪表盘按状态统计客户数量" is the standard magic-flow prompt). An empty chart on first open reads as "the AI built a broken app" — it undoes the entire publish pipeline's credibility for the cost of one missed re-render.
Repro
- cloud rig
run-stack.sh --with-ui, build an app via the build agent with a dashboard (pie or bar) bound to a real dataset. - Publish; from the launcher open the app → dashboard nav entry.
- First render: empty chart area. Reload: chart paints.
Suspected class: the chart mounts before its dataset query resolves (or before the container has measured dimensions) and never re-draws when data arrives — race, not data. Not bisected; the fix owner should instrument mount/data-arrival ordering in the dashboard widget renderer.
Activity
os-zhuang commentedon Aug 21, 2026
Triage: queued, type Bug — maintainer-filed live repro (first screen of every AI-built app; empty chart on first mount, repaints on reload; chart-type-independent, survived a week of main). Not yet bisected: the first deliverable is instrumenting mount/data-arrival ordering in the dashboard widget renderer, then the fix. Suspected class is a missed re-render race, not data. Size/model suggestion: M, opus.
Generated by Claude Code
os-zhuang commentedon Aug 22, 2026
Half-state report from the
domain:uiexecution seat (#5560) — not a claim, and not this seat's card to grade.Surfaced during round 17's lane inventory. This card is the only
pm:dispatchedissue in the repo outside this seat's own in-flight set, and it carries an inconsistent pair:pm:dispatchedis set, but there is no assignee — so the state machine says "in flight" while the assignee field says "unclaimed". Those cannot both be true.Claim:comment on the thread and no branch or PR referencing it.Under the stale-claim rule that pairing reads as a dispatch whose dev died before it ever claimed, or a label write whose partner never landed. Either way the honest resolution is to drop
pm:dispatchedand return it to the queue, or re-dispatch it — but it carries nodomain:*label, so it is not in any lane and this seat has no standing to do either. ⛔ Deliberately not touched.Flagging for triage: it needs a lane label first, then a state repair. The underlying defect it describes (dashboard chart widgets empty on first mount, repainting on reload) is a first-screen bug on AI-built apps, so it is not a card worth leaving in limbo.
Generated by Claude Code
os-zhuang commentedon Aug 22, 2026
Re-queued by maintainer instruction. Executing under the standing direct-dispatch channel; the instruction is quoted verbatim rather than paraphrased, per the rule that a state change made on someone else's authority carries its provenance:
Maintainer, 2026-08-22: 「5451 重新入队」.
State repaired in one label write:
pm:dispatched→pm:queue.bugretained. The card had no assignee to clear.What this fixes. As reported above, this card was carrying
pm:dispatchedwith no assignee and no branch or PR since 2026-08-21T07:26Z — the state machine said "in flight" while the assignee field said "unclaimed", so it was invisible to every candidate query (which requirepm:queue) and to stale-claim reclaim (which keys off an assignee). It could sit there indefinitely without any sweep noticing. It is now an ordinary queue card.⛔ Still not dispatchable, and this is the remaining gap: the card carries no
domain:*label, so it belongs to no lane and no execution seat can claim it — under the standing rule, an unlabelled issue means triage has not reached it yet, not that a seat may self-judge. Routing is triage's single-producer call and this seat has not made it.For triage's benefit, the routing question looks answerable from the card itself: the defect is in dashboard chart widgets (pie and bar) rendering empty on first mount and repainting on reload. If the fix lands in⚠️ Stated as a hint for whoever grades it, not as a label this seat is applying.
plugin-dashboardor the chart renderers, that isdomain:uiand this seat will take it.Generated by Claude Code
fix(plugin-charts): put the chart min-height floor on the element Rec…
fix(plugin-charts): keep the height chain intact through ObjectChart'…
feat(chatbot): confirm card carries the replay's terminal state — app…