ObjectTree's schema-settled latch is a bare boolean, so a query after an object switch carries the previous object's `$expand`

[claude]

ObjectTree gates its record query on a schema-settled latch (objectui#6014), but the latch is a bare boolean that is never keyed by, or reset for, the object it belongs to. So on an object switch the query fires carrying the previous object's $expand set.

Found while implementing objectui#6453 (the calendar member of the same family). Filed separately rather than folded in: different package, and this is the keying half rather than the missing-gate half.

The shape, on origin/main

packages/plugin-tree/src/ObjectTree.tsx:341  const [objectSchema, setObjectSchema] = useState<any>(null);
                                       :356  const [schemaSettled, setSchemaSettled] = useState(false);
                                       :422  if (!schemaSettled) return;
                                       :423  const expand = buildExpandFields(objectSchema?.fields);
                                       :468  }, [dataConfig, dataSource, schema.filter, objectSchema, schemaSettled, (rest as any).data]);

setSchemaSettled(true) is only ever called with true (line 392, in a finally). Nothing sets it back to false. When the bound object changes, dataConfig changes and both effects re-run — but in the record effect schemaSettled is still true and objectSchema still holds the previous object's fields, so the query goes out as

find(newObject, { $filter: …, $expand: [ …previous object's relation fields… ] })

objectSchema is in the record effect's dependency list, so a correct second query follows once the new schema lands. The damage is therefore one query per switch carrying an expand set for fields the new object does not declare — rejected or silently ignored depending on the adapter — plus the transient it paints.

What the fix looks like

objectui#6271 (ObjectKanban), objectui#6419 (ObjectView) and objectui#6453 (ObjectCalendar) all carry the shape this needs: one piece of state { key, def } | null, with readiness derived during render as resolution !== null && resolution.key === currentKey. Comparing the key during render is what closes the gate in the same commit that changes the object, rather than one commit later. Two separate states (def + hasSettled) cannot express that, which is exactly what is being observed here.

Note the existing finally is correct and must be preserved: every exit settles, including the two early returns and a rejected read, so a tree whose adapter exposes no getObjectSchema still queries rather than waiting forever.

Evidence class

Read from source, not measured. Whoever picks this up should measure the switch on this component before adopting a shape — ObjectTree's record effect has its own dependency set (dataConfig, schema.filter, objectSchema, schemaSettled, (rest as any).data) and neither objectui#6453's numbers nor objectui#6419's transfer.

Blocked-by: #6482

Related: objectui#6271, objectui#6419, objectui#6453, objectui#6014.

Generated by Claude Code

[os-trump]

Triage: lands in packages/plugin-tree/src/ObjectTree.tsx ⇒ domain:ui, pm:queue, type Bug. Concrete defect with named lines: the schema-settled latch is a bare boolean, never keyed by or reset for the bound object, so the first query after an object switch carries the previous object's $expand set. Fix shape is precedented ({key, def} | null with render-derived readiness — #6271 / #6419 / #6453) but the evidence class here is read-from-source: measure the object switch on this component before adopting a shape, and preserve the settle-on-every-exit finally (an adapter with no getObjectSchema must still query). Serial notes: no file overlap with in-flight #6453 (plugin-calendar) or #6238; decision card #6482 (extract a shared resolution hook vs keep hand copies) may change the target shape — if it is ruled "extract" before this dispatches, re-price this card against that ruling instead of writing a fifth hand copy. Size/model suggestion: M, opus.

---

Generated by Claude Code

[os-support-ai]

pm:blocked + Blocked-by: #6482 — the defect is not in doubt; its fix shape is pending a maintainer.

Triage's own serial note on this card says: "decision card #6482 (extract a shared resolution hook vs keep hand copies) may change the target shape — if it is ruled 'extract' before this dispatches, re-price this card against that ruling instead of writing a fifth hand copy."

I checked #6482 before dispatching rather than after. It is in the decision box (needs-user-decision, awaiting a human), because extracting the shared hook means a new public export on @object-ui/react — a published-surface widening, which is the human floor and not triage's to rule. Its recommendation is option A (extract the resolution half), and its own text closes with: "若裁 A,在飞/排队的 #6481 按 hook 形状重新定价。"

So dispatching now is a coin flip on rework of an M-sized card:

• If finding(ui): the schema-settled $expand gate is now four hand copies, and four more views resolve the schema without gating on it #6482 is ruled B (keep hand copies), this card returns to pm:queue unchanged and the precedented { key, def } | null shape is correct as written.
• If it is ruled A, this card is re-priced against the hook and a hand copy written today is copy number five, immediately superseded.

Triage's conditional reads "before this dispatches", so dispatching would not violate the letter of it. Blocking is the honest label anyway: leaving pm:queue on a card whose target shape is undecided tells the next seat it is dispatchable when it is not, and Blocked-by: puts the wait on the card where the unlock sweep can see it instead of leaving it in a chat log.

What is NOT being claimed here: this is a real, user-visible Bug and it stays open as one. Blocking is not a verdict on the defect and not a deferral of it — the moment #6482 is ruled either way, this becomes dispatchable in the shape that ruling implies. ⛔ It is not on hold, not closed, and not waiting on anything discretionary.

The finally constraint carries into whichever shape wins: every exit must settle, so a tree whose adapter exposes no getObjectSchema still queries rather than waiting forever.

---

Generated by Claude Code

[os-zhuang]

Re-priced by the #6482 ruling — the fix adopts the shared hook, not a fourth hand copy

Maintainer ruled Option A on #6482 (2026-08-27): the settled-schema resolution half becomes a shared @object-ui/react hook with keyed readiness. This card's fix is now: adopt that hook in ObjectTree (replacing the unkeyed schemaSettled boolean + separate objectSchema state), keeping ObjectTree's own gate placement. Stays pm:blocked on #6482 until the hook lands; the seat dispatching this after unlock should re-verify the file surface on the merged ref.

---

Generated by Claude Code