`listViews` has the same swallow objectui#7741 just removed from `listImportMappings` — a refused metadata read renders as "this object has no saved views"

[os-justin]

⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned, out of scope, from the objectui#7741 round.

The behaviour

packages/data-objectstack/src/index.ts, ObjectStackAdapter.listViews — measured on origin/main 21d7989fb, the catch arm at :4893-4896 (the sibling arm objectui#7741 was about was at :4663 on the same tree):

} catch (err) {
  console.warn('[OBJECTSTACKDataSource] listViews failed:', err);
  return [];
}

The read it wraps is this.client.meta.getItems('view'). So a view list that was refused (401 / 403), or that failed (5xx, a dropped connection), returns the identical value as a view list the server served empty — and every consumer of listViews reads only the return.

Why this is the same defect, not a lookalike

objectui#7741 is the identical shape one method over: listImportMappings collapsed 「the server does not serve this kind」 and 「the server refused or errored」 into one empty array, with a console.warn as the only discriminator, and that ambiguity produced a confident wrong diagnosis in objectstack#14026. The governing precedent is framework #13906 decision 1 option A — a thing that could not be READ is not a thing that is ABSENT.

⚠️ The user-visible cost here is arguably worse than the one objectui#7741 paid, and this is the part worth grading. A missing saved-mapping selector is an absent convenience. An empty listViews is the object's view switcher: a user whose token lapsed mid-session can be shown an object that appears to have no saved views at all, including views they created, with nothing on screen saying the list is an artefact of a failed read.

⛔ What is NOT claimed

⛔ Not that the degrade itself is wrong. As with objectui#7741, degrading to an empty list keeps an older or partial deployment working, and that half should stay. What is missing is the discrimination — reading the failure from err itself rather than from the emptiness of the result.

⛔ Not that the fix is mechanical. listViews's quiet arm is not obviously the same population as listImportMappings': view is a long-standing declared kind, so 「an older server without this kind」 is not the story here, and which failures deserve to stay quiet needs its own reading. That is exactly why this was NOT folded into the objectui#7741 PR.

The machinery to reuse already landed

The objectui#7741 PR added, in this same file:

• classifyImportMappingsFailure(err) — reads the ADR-0112 code first, the status only where no code was declared, never the emptiness of the result.
• ObjectStackAdapter.onMetadataReadWarning(cb) and MetadataReadWarningEvent — a subscribe/unsubscribe channel alongside the unchanged return, already wired to a toast by app-shell's AdapterProvider.

MetadataReadWarningEvent's operation and kind are deliberately single-member unions today, precisely so a second emitter is an additive, reviewed widening rather than something a consumer's exhaustive switch discovers at runtime. Adding listViews to that channel is the widening this card is about.

Why it was not done in that PR

That card's dispatch scoped it to listImportMappings and its triage said in as many words ⛔ 不要自行扩面 (do not widen the surface unbidden). Adding a second emitter would also have widened the published event union and added a verification surface the card's gate set did not cover.

Re-check

git -C objectui grep -n "console.warn('\[OBJECTSTACKDataSource\]" origin/main -- packages/data-objectstack/src/index.ts

Two hits on origin/main 21d7989fb: listViews and listImportMappings. Only the second one has been addressed.

Related

objectui#7741 (the sibling this was found from) · objectstack#14026 (the misdiagnosis the sibling's silence produced) · #13906 decision 1 option A (the governing discrimination).