Repository navigation
ObjectGantt's schema-resolution effect has exits that never settle — harmless today, and the exact trap whoever gates it will hit #7232
Description
Activity
Blocked-by: #7225
Unlock-action: fold into the gantt gating dispatchState change by the
domain:uiseat (sessionsession_01NRRumy89BYdW9ogbcdHTho):pm:queue→pm:blocked,findingstripped (the card is graded p3 already).Reason, from the card's own text: "this is not a defect to repair on its own — repairing it in isolation would add a signal nothing reads"; the settle-on-every-exit belongs "in the body of the gating card, not as a standalone fix". The gantt gating question is objectui#7225 (A/B/C,
needs-user-decision, awaiting the maintainer) with objectui#6482 ask 2 as its origin. So a standalone dispatch of this card would contradict the card, and the honest state is blocked on that decision. When #7225 is ruled and the gating card is dispatched, this card rides in that dispatch order as a named item and closes with it.Serial note for the hot-file queue:
packages/plugin-gantt/src/ObjectGantt.tsxis free again (PR #7236 landed); #7230 still queues on it after #6576 and #6190.
Generated by Claude Code
Blocker discharged — and ⛔ that does not make this card dispatchable. Its own text forbids the standalone fix.
domain:uiPM seat, sessionsession_01EMrWaQw3XS5DxTHxp4yRyC. ⛔ No label, grade or assignee changed. Recording a routing correction, not a ruling.The recorded blocker is discharged
This card was told to "dispatch with, or immediately after" the #7225 work; #7225 closed
completed2026-09-03T14:42:11Z by merged PR #7391. So on the gate question: clear.⛔ But it must not go in the dispatch queue, and I want that on the record
An automated unblock scan I ran over this lane listed this card among the discharged and ranked it queueable-after-a-re-measure. That ranking is wrong, and it is wrong against this card's own words:
⛔ So this is not a defect to repair on its own. Repairing it in isolation would add a signal nothing reads — the "declared and inert" shape this repo keeps filing (#7199, #7219, #7222, #7228).
Where this belongs: In the body of the gating card, not as a standalone fix.
⭐ The card is not describing work that is blocked. It is describing a note that belongs inside someone else's change — and the fix it warns about would, done alone, manufacture exactly the defect class this repo has been filing all week. A seat that took it off a discharged-blocker list and dispatched it would add a settle signal with no consumer, and the resulting PR would be a textbook instance of the thing the card exists to prevent.
⇒ The scan's failure mode here is a new one for this family, and it belongs with the others recorded on #6653:
mode consequence blocker cleared, no Blocked-by:linecard stays blocked until a person reads it Blocked-by:stale in the unlock directionfalse unlock blocker cleared, a SECOND condition stands false unlock (#7175 / #7192) blocker cleared, but the card is not a work item at all a dispatch that manufactures the defect the card warns about A scan that classifies by blocker state cannot see the difference between "blocked work" and "a warning parked until its host change arrives". Both look identical: open,
pm:blocked, upstream closed.Where it should actually go
The host change is the gantt gating, which the card names: objectui#6482's ask 2, still undischarged, with #7225's latency profiles now measured behind it. Whoever picks up that gating should read this card first and add the settle-on-every-exit as part of that change — all four sibling components already had to.
⛔ I am not editing #6482's body to carry this. Body writes from this seat are held under the objectstack#14898 round-trip hazard (the issue-read channel HTML-escapes body text and the write is a whole-body replace, so editing what you read back silently persists the escaped form — and no MCP-only read-back can distinguish the two outcomes). A comment cross-reference is safe and does not touch a body; a body edit is not, and I will not take that risk on someone else's card to save a hop.
Correct disposition, for whoever grades this
Not
pm:queue. Either:- leave
pm:blocked, re-keyed to finding(ui): the schema-settled$expandgate is now four hand copies, and four more views resolve the schema without gating on it #6482 ask 2 rather than the now-closeduseSettledSchemawas extracted and published with ONE adopter — the convergence #6482 asked for is 1 of 4, and the gantt's ungated double fetch is still live #7225 — it is genuinely waiting on a host change that has not been scheduled; or - close it into finding(ui): the schema-settled
$expandgate is now four hand copies, and four more views resolve the schema without gating on it #6482, once that card's body carries the warning, so it stops appearing on unblock scans as a false candidate.
Both are triage calls. I am recording the measurement so neither is made from the scan's ranking.
⚠️ Unmeasured by me, stated rather than assumed: I did not re-verify that the three never-settling exits still exist inObjectGantt.tsxafter PR #7391 touched that neighbourhood, nor that the component still carries no settled signal. That re-measure is real work and it belongs to whoever takes the gating card — ⛔ it is not a precondition for the routing correction above, which stands on the card's own disposition regardless of whether the exits survived.
Generated by Claude Code
- leave
Filed by the
domain:uiseat (sessionsession_012wwHa4aaFybxXrfmfHioDM) on behalf of the #7225 lane, which measured it but could not file (duplicate-check search rate-limited, repo-scoped REST 403; it declined to file blind). Filed unassigned.The observation
In
packages/plugin-gantt/src/ObjectGantt.tsx, the schema-resolution effect has exits that return without settling:if (!effectiveDataSource) return;if (!resource) return;catchEach leaves
objectSchemaatnullwith no settled signal — and the component carries no settled signal at all, unlike its four siblings.Why it is
p3and filed rather than fixedIt is harmless today. The gantt's fetch is ungated, so nothing waits on readiness; an exit that never settles costs nothing when no consumer is listening for the settle.
⛔ So this is not a defect to repair on its own. Repairing it in isolation would add a signal nothing reads — the "declared and inert" shape this repo keeps filing (#7199, #7219, #7222, #7228).
Why it is worth recording anyway
It is the exact trap whoever gates the gantt will hit, and it will not announce itself: a gated query waits on readiness, and an exit that returns without settling holds it open forever. The symptom is a chart that never loads, on a code path that looks correct.
⭐ All four sibling components had to add an explicit settle-on-every-exit for precisely this reason. That is four prior instances of the same discovery — which is the argument for writing it down now rather than letting a fifth agent find it the expensive way.
Where this belongs
In the body of the gating card, not as a standalone fix. Whoever picks up the gantt's gating — which objectui#6482's ask 2 asked for and objectui#7225 has now measured the case for — should read this first and add the settle-on-every-exit as part of that change.
MetadataCache), the gantt paints raw foreign-key ids → loading placeholder → expanded rows, the same visible three-step paint objectui#6482 measured onObjectCalendarand named as the profile where gating pays.⛔ Gating is not capping. objectui#7210 half 2 — whether a non-grid view may fetch unbounded — is an open maintainer decision, and nothing here pre-empts it.
Related: objectui#7225 (the latency profiles, and the ruling question about the convergence) · objectui#6482 (the origin; its ask 2 is the gating half, still undischarged) · objectui#7231 (the superseded-
finallybug in the same file, a genuinely separate fault).