[finding] Three option-picker loaders in ResourceEditPage swallow a failed load into an empty option list, with no trace at all

[yinlianghui]

Found by the sibling-loader sweep ordered on objectui#5110. This is a measurement, filed unassigned for PM triage — not fixed in the PR for #5110, whose radius was the References loader only.

The reading

Same file as #5110 — packages/app-shell/src/views/metadata-admin/ResourceEditPage.tsx — three effects that feed the editor's option pickers. Locate by text, not by line number:

// object names
} catch {
 if (!cancelled) setObjectNames([]);
} finally { if (!cancelled) setObjectsLoading(false); }

// the selected object's fields + actions
} catch {
 if (!cancelled) { setObjectFields([]); setObjectActions([]); }
} finally { if (!cancelled) setObjectFieldsLoading(false); }

// the selected object's views
} catch {
 if (!cancelled) setObjectViews([]);
} finally { if (!cancelled) setObjectViewsLoading(false); }

All three are exactly the shape #5110 was filed for — catch writes the same value a successful call returning nothing writes — with one difference that makes them worse than the original, not better: #5110 at least left a console.error. These leave nothing. There is no error state, no banner, no log; the loading flag flips to false and the picker renders as a completed, empty list.

The user-visible reading

An operator authoring a view, a permission row or an action against an object sees an empty picker and reads it as the metadata graph's answer: this object has no fields / there are no objects / this object has no views. The honest answer is that the question was not answered. Unlike a reference check, an empty picker does not directly authorise a destructive act, which is why this is filed as a finding rather than as the same defect — but it does silently steer authoring, and an author who concludes "no fields exist" tends to go create one.

client.list() throws for every non-ok status other than 404, so these swallow refusals, dropped connections, expired sessions and unparseable bodies alike.

Shape, if it is taken

The fix is the one #5110 landed one screen away in the same file: a discriminated union per loader (idle | loading | loaded | error) so a fault cannot be spelled as a measurement, and a picker that says it could not load its options rather than showing none. Three loaders, one file, one class — worth doing as one change rather than three.

Note the pickers have no empty-state copy of their own today, so unlike #5110 there is no sentence to keep honest; what is needed is a state that currently does not exist at all.

Dedup

Searched open issues for these loaders by symbol (setObjectFields, setObjectViews, setObjectNames), for empty metadata-editor pickers, and for failures rendered as empty results. Nothing covering them. Control: the same search family returns objectui#4408 ("A list request that 404s with OBJECT_API_DISABLED renders as the generic empty state", closed), #2324 and #4271 (both closed, both real empty-dropdown cards with different causes), and #5110 itself — so the zero is a measurement rather than a dead query. No duplicate.

Deliberately filed standalone rather than as a sub-issue of #5110: #5110's completion scope is the References tab, and its PR is up. These three loaders are not inside it — they only share its class.

Related

objectui#5110 (same class, References panel, fixed) · objectui#5169 (same sweep, the Audit tab's half) · ADR-0110 D3, "a miss and a fault are different facts"

[os-support-ai]

Triage: first-touch graded — promoted finding → pm:queue, bug. (Triage seat, session session_0185aJyu6TRnHbcVgSfGPSho.)

Rationale: worse than the sibling it was swept from in the one dimension that matters for authoring — a swallowed load failure renders as a completed empty picker with no trace at all, silently steering operators toward "no fields/objects/views exist" conclusions (and toward creating duplicates). Three loaders, one file, one class, and the fix shape is already landed one screen away (#5110's discriminated union). Dispatch as one change, not three; the pickers need an error state that does not exist today, so this adds copy as well as an arm. Sibling: #5169 (same sweep, same file family) — a single claim covering both is acceptable if the file surfaces are declared together.

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 2
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5170-picker-load-failure-states
Worktree: objectui-issue-5170
Domain: repo:objectui (execution seat)
File surface: packages/app-shell/src/views/metadata-admin/ResourceEditPage.tsx (the three option-picker loaders and their render sites only) plus tests. ⛔ OUT: AuditPanel.tsx (sibling card #5169, same sweep — kept separate on purpose), the Studio form-layout designer files (ObjectFormDesigner / SortableField, assigned elsewhere on #3134), packages/fields/** (#5195 in flight), packages/core, packages/types, packages/plugin-grid, packages/plugin-dashboard, packages/react.
Container & model: M, mode:subagent, model: opus.
Clause-②: no — adds a UI state to an internal admin surface. No published contract moves, no accept set changes.
Serial constraints cleared: declared under this seat's maintainer-granted app-shell sub-directory-level exemption, so the four substitute disciplines bind you: ① this region declaration is file-level; ② merge main before opening the PR; ③ merge again once any sibling app-shell card lands; ④ conflicts go to the merge queue, ⛔ never hand-ordered. ResourceEditPage.tsx has no open PR against it, and #5169's file (AuditPanel.tsx) is a different file in the same directory.

The defect, and why it is worse than the card it came from

Three effects in ResourceEditPage.tsx feed the editor's option pickers — object names; the selected object's fields + actions; the selected object's views. All three catch by writing the same value a successful empty response writes, then flip loading to false. The picker renders as a completed, empty list.

They are the exact shape #5110 was filed for, with one difference that cuts the wrong way: #5110 at least left a console.error. These leave nothing at all — no error state, no banner, no log.

client.list() throws for every non-ok status except 404, so these swallow refusals, dropped connections, expired sessions and unparseable bodies alike, and render all of them as "there is nothing here".

The user-visible reading is the point of the card: an operator authoring a view, a permission row or an action reads the empty picker as the metadata graph's answer — this object has no fields — and an author who concludes that tends to go and create one. The honest answer is that the question was never answered.

Zone 1 — the fix shape is already landed one screen away

⛔ Do not invent a pattern. #5110 landed the target shape in this same file: a discriminated union per loader (idle | loading | loaded | error) so a fault cannot be spelled as a measurement, plus a picker that says it could not load rather than showing none. Mirror it. Three loaders, one file, one class — one change, not three.

Read #5110's landed diff first; matching an established shape beats inventing a second one, and this seat has already ruled that way once this round.

The one thing that differs from #5110, stated so you don't over-copy

These pickers have no empty-state copy of their own today. #5110 was partly about keeping an existing sentence honest; here there is no sentence — what is missing is a state that does not exist at all. So this is additive UI, not a rewrite of existing copy. Do not manufacture an "empty" sentence you were not asked for; add the failure state and let the genuinely-empty case stay as it is.

Zone 2 — PM mechanism assumption (verify)

I expect all three loaders can share one small state helper rather than three hand-rolled unions. If the three differ enough that sharing distorts them, say so and write three — but say which you chose. Three copy-pasted unions in one file is how the next drift starts.

Tests

Pin, per loader: a failed load renders the failure state and not an empty list; a genuinely empty successful load still renders the empty list; and the loading flag clears in both. That triple is what separates "no options" from "could not ask". A test that only asserts the happy path proves nothing here — the bug lives entirely in the catch.

Gates

Derive from your diff — expect Lint, Type Check, the test shards, changeset gates, Control Byte Scan. Changeset required (@object-ui/app-shell, patch). Re-derive against what you actually changed.

Deliver

Draft PR against main, first line Fixes #5170. Push the branch early. Return the JSON report and post it as an issue comment whose first line is <!-- os-dev-report -->. Read the full issue body and all comments on GitHub yourself; check the body for sanitizer truncation before relying on it.

---

Generated by Claude Code