The "Used by" panel collapses every references() failure into "Safe to delete" — a server error is rendered as a measured empty result #5110

Found while implementing objectstack#9326 (objectstack PR #9425), which fixes the producer half of this in @objectstack/rest. Filed separately because the fix lands here, in objectui.

The measurement

packages/app-shell/src/views/metadata-admin/ResourceEditPage.tsx — the References tab loader (around line 793; locate it by text, not by line number):

setRefsLoading(true);
try {
  const r = await client.references(type, name);
  setRefs(r);
} catch (err) {
  setRefs([]);
  console.error('references() failed', err);
} finally {
  setRefsLoading(false);
}

setRefs([]) is the same state a successful call returning zero references produces. And ReferencesPanel renders that state as, verbatim from metadata-admin/i18n.ts:

'engine.edit.refsEmptyDesc': 'Nothing in the metadata graph points at this item. Safe to delete.'

So any failure — the server refused, the network dropped, the session expired, the response was unparseable — is shown to the operator as an affirmative, measured statement that nothing depends on this item, and that deleting it is safe. The only trace is a console.error nobody is looking at. The user is typically on this panel because they are about to delete something.

MetadataClient.references() (packages/data-objectstack/src/metadata-client.ts) does its half correctly: it returns [] only for a 404, and throws parseError(res) for every other non-ok status. The information reaches this component intact and is discarded here.

Why now

@objectstack/rest used to answer 200 {references: []} when the resolved protocol had no findReferencesToMeta method — a capability gap rendered as "nothing depends on this item". objectstack#9326 / PR #9425 changes that branch to refuse:

501  { error: { code: 'NOT_IMPLEMENTED', message: '...' } }

That makes the wire honest. It does not by itself remove the user-visible harm, because this catch turns the truthful 501 straight back into "Safe to delete." The producer fix is necessary and not sufficient; this is the other half.

Not blocked by it, though. The catch swallows failures today, for every cause listed above, and can be fixed independently of what the server sends.

What would close it

An error state distinct from the empty state. Note that the current shape has no room for one: ReferencesPanel reads refs == null as still loading —

if (loading || refs == null) return <spinner/>;
if (refs.length === 0) return <Empty>…Safe to delete…</Empty>;

— so simply not setting refs on failure leaves a permanent spinner, and setRefs([]) is the lie. A third state is needed (an error field, or a discriminated union for the panel's data), plus copy for it. Suggested shape, not asserted: the panel says the check could not be completed and offers a retry, and deliberately says nothing about whether deletion is safe — the honest answer when the question was not answered.

⚠️ Worth checking while in there whether the same catch → empty pattern appears on the sibling tabs this page loads (history, audit, diagnostics). A zero there needs its own control query before it is reported as a zero.

Related

objectstack#9326 / objectstack PR #9425 (the producer half — the REST route now refuses instead of answering empty) · objectstack#9426 (the same producer-side defect class on the audit route) · ADR-0110 D3, "a miss and a fault are different facts"

Dedup

Searched open issues here for the references panel, the "Safe to delete" empty state, and ResourceEditPage error handling; nothing covering this. Control query on the same repo (metadata admin resource edit page) returned three real, related cards (#4308, #4518, #4132, all closed), so the zero above is a measurement rather than a broken search. No duplicate.