⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned from the #14026 measurement round, which ⛔ could not fix it in-round: that round was scoped to a measurement and widening was forbidden.
The behaviour
packages/data-objectstack/src/index.ts:4510, listImportMappings:
try {
const result = await this.client.meta.getItems('mapping');
const items = Array.isArray(result?.items) ? result.items : Array.isArray(result) ? result : [];
return items.filter((m) => m && m.targetObject === objectName);
} catch (err) {
console.warn('[OBJECTSTACKDataSource] listImportMappings failed:', err);
return [];
}Its docblock states the degrade as intentional: 「a failure (older server without the mapping kind) degrades to an empty list, so the selector simply doesn't appear」. That is a reasonable default — an older server should not break the wizard.
⭐ The cost, which this round paid in full
A refused or broken door is indistinguishable, in the UI, from 「no mapping is registered」. Both render as: no selector.
That is not hypothetical. It is exactly what produced #14026: a downstream PM took a wire capture, saw no mappingName and writeMode: "insert", and concluded — reasonably — that the wizard hardcodes the client. The card was filed against objectui, routed to a repo whose wizard has been correct and released since 17.1.0, and consumed two seats before a measurement round established that every measurable half on this side is right.
⇒ the silent degrade did not just hide a failure. It produced a confident, wrong diagnosis in a careful reporter, and the misdiagnosis travelled further than the fault would have.
⚠️ The console.warn exists, but it is the only discriminator between 「served empty」 and 「refused」, it is in the browser console, and nothing in the UI points at it. A user who does not have devtools open sees a feature that is simply absent.
What would close it
⛔ Not this seat's design. The shape the round recommended: keep the empty-list degrade for the selector — the older-server case is real and should stay quiet — but surface the failure where someone can act on it: a wizard-level notice, or a structured warning the adapter's consumers can read. ⭐ The distinction to preserve is 「the server does not serve this kind」 (quiet, supported) versus 「the server refused or errored」 (loud), which is the same discrimination the framework applies at its own tenancy-posture seam under #13906 decision 1 option A: a thing that could not be READ is not a thing that is ABSENT.
Published
Yes — @object-ui/data-objectstack@17.1.0 ships listImportMappings with this identical swallow (measured by npm pack during the #14026 round).
Related
objectstack#14026 (the card this behaviour misdirected) · objectui#7738 (the consumer pin the round shipped) · objectstack#15907 (no producer-side pin on the served item shape) · #13906 decision 1 option A (the same discrimination, applied at the framework's tenancy seam).
Generated by Claude Code
⛔ Ungraded and unrouted —
domain:*, priority and type are triage's. Filed unassigned from the #14026 measurement round, which ⛔ could not fix it in-round: that round was scoped to a measurement and widening was forbidden.The behaviour
packages/data-objectstack/src/index.ts:4510,listImportMappings:Its docblock states the degrade as intentional: 「a failure (older server without the
mappingkind) degrades to an empty list, so the selector simply doesn't appear」. That is a reasonable default — an older server should not break the wizard.⭐ The cost, which this round paid in full
A refused or broken door is indistinguishable, in the UI, from 「no mapping is registered」. Both render as: no selector.
That is not hypothetical. It is exactly what produced #14026: a downstream PM took a wire capture, saw no
mappingNameandwriteMode: "insert", and concluded — reasonably — that the wizard hardcodes the client. The card was filed againstobjectui, routed to a repo whose wizard has been correct and released since 17.1.0, and consumed two seats before a measurement round established that every measurable half on this side is right.⇒ the silent degrade did not just hide a failure. It produced a confident, wrong diagnosis in a careful reporter, and the misdiagnosis travelled further than the fault would have.
console.warnexists, but it is the only discriminator between 「served empty」 and 「refused」, it is in the browser console, and nothing in the UI points at it. A user who does not have devtools open sees a feature that is simply absent.What would close it
⛔ Not this seat's design. The shape the round recommended: keep the empty-list degrade for the selector — the older-server case is real and should stay quiet — but surface the failure where someone can act on it: a wizard-level notice, or a structured warning the adapter's consumers can read. ⭐ The distinction to preserve is 「the server does not serve this kind」 (quiet, supported) versus 「the server refused or errored」 (loud), which is the same discrimination the framework applies at its own tenancy-posture seam under #13906 decision 1 option A: a thing that could not be READ is not a thing that is ABSENT.
Published
Yes —
@object-ui/data-objectstack@17.1.0shipslistImportMappingswith this identical swallow (measured bynpm packduring the #14026 round).Related
objectstack#14026 (the card this behaviour misdirected) · objectui#7738 (the consumer pin the round shipped) · objectstack#15907 (no producer-side pin on the served item shape) · #13906 decision 1 option A (the same discrimination, applied at the framework's tenancy seam).
Generated by Claude Code