Filed unassigned from #7802, which registered the map's first entry. Observation class — no user hits this; the cost is that the comment misprices a decision future authors make by reading it.
What the comment says
packages/spec/src/data/api-methods-batch-conformance.test.ts, on SINGLE_RECORD_WRITE_ONLY:
Adding an entry is a real decision — batch denial is invisible until a user multi-selects rows and data-objectstack rethrows the 405 without falling back to per-row writes. Write down why the object is worth that.
That sentence is the map's whole pricing model: it tells the author an exemption buys a hard user-visible error.
Why it is not accurate
It restates the original body of #3757, which #3757's own author retracted twice after getting the objectui source, and which was then closed not planned. Re-verified today against the console build this release pins (.objectui-sha 6314e87f2):
| Layer |
Behaviour |
data-objectstack bulkUpdate / bulkDelete |
does rethrow — this half of the sentence is right |
its only caller, useBulkExecutor → executeBulkBatch (packages/core/src/actions/bulkFastPath.ts) |
try { bulkCall } catch { /* Fall through to per-row */ } — falls back on any throw, 405 included, and reports per-row (id, error) detail |
the console object grid's multi-select delete (packages/app-shell/src/hooks/useObjectActions.ts:99-100) |
Promise.allSettled(records.map(r => dataSource.delete(...))) — never calls bulkDelete at all |
So the adapter's rethrow is caught one layer up, and the console's own bulk-delete path does not reach the adapter's bulk primitive in the first place. The real cost of a batch exemption is a wasted round trip followed by N per-row writes, not a hard error.
Why it is worth recording
The comment is load-bearing by design — it is the instruction the exemption map gives whoever is deciding whether to widen an object or exempt it, and it inflates one side of that trade. #7802's decision does not depend on it (it went the other way: a cheaper denial argues for the exemption, and the deciding evidence was that no multi-select surface exists for sys_api_key at all), which is why this is filed rather than fixed in that PR.
Also worth folding in from #3757's second correction, since it bears on the same paragraph: the grid's built-in bulk-delete entry gates on the child verb delete, not on bulk, and gating it on bulk would be a regression — an object granting delete without bulk keeps a working multi-select delete via the fallback. So "batch denial is invisible" is true in a narrower sense than the comment implies: nothing is hidden from the user, and nothing fails.
Suggested fix
One paragraph in the test file: replace the disproven consequence with the real one, cite #3757's two corrections so the next reader does not re-derive it a fourth time, and keep the instruction ("write down why") unchanged — that part is right and is what made #7802's entry come with evidence.
Filed unassigned from #7802, which registered the map's first entry. Observation class — no user hits this; the cost is that the comment misprices a decision future authors make by reading it.
What the comment says
packages/spec/src/data/api-methods-batch-conformance.test.ts, onSINGLE_RECORD_WRITE_ONLY:That sentence is the map's whole pricing model: it tells the author an exemption buys a hard user-visible error.
Why it is not accurate
It restates the original body of #3757, which #3757's own author retracted twice after getting the objectui source, and which was then closed
not planned. Re-verified today against the console build this release pins (.objectui-sha6314e87f2):data-objectstackbulkUpdate/bulkDeleteuseBulkExecutor→executeBulkBatch(packages/core/src/actions/bulkFastPath.ts)try { bulkCall } catch { /* Fall through to per-row */ }— falls back on any throw, 405 included, and reports per-row(id, error)detailpackages/app-shell/src/hooks/useObjectActions.ts:99-100)Promise.allSettled(records.map(r => dataSource.delete(...)))— never callsbulkDeleteat allSo the adapter's rethrow is caught one layer up, and the console's own bulk-delete path does not reach the adapter's bulk primitive in the first place. The real cost of a batch exemption is a wasted round trip followed by N per-row writes, not a hard error.
Why it is worth recording
The comment is load-bearing by design — it is the instruction the exemption map gives whoever is deciding whether to widen an object or exempt it, and it inflates one side of that trade. #7802's decision does not depend on it (it went the other way: a cheaper denial argues for the exemption, and the deciding evidence was that no multi-select surface exists for
sys_api_keyat all), which is why this is filed rather than fixed in that PR.Also worth folding in from #3757's second correction, since it bears on the same paragraph: the grid's built-in bulk-delete entry gates on the child verb
delete, not onbulk, and gating it onbulkwould be a regression — an object grantingdeletewithoutbulkkeeps a working multi-select delete via the fallback. So "batch denial is invisible" is true in a narrower sense than the comment implies: nothing is hidden from the user, and nothing fails.Suggested fix
One paragraph in the test file: replace the disproven consequence with the real one, cite #3757's two corrections so the next reader does not re-derive it a fourth time, and keep the instruction ("write down why") unchanged — that part is right and is what made #7802's entry come with evidence.