data: PATCH/DELETE of a nonexistent record answer 200 success instead of RECORD_NOT_FOUND

[baozhoutao]

Found while verifying the 17.0.0-rc.1 checklist on #3909 (F3, the "silent drops became refusals" axis). Verified on main @ 1ee48bc60, showcase under os serve --dev, admin session.

The read path already answers honestly, but both single-record write paths report success for a record that does not exist:

GET    /api/v1/data/showcase_task/definitely_not_a_row
→ 404 {"error":"Record … not found in showcase_task","code":"RECORD_NOT_FOUND",…}   ✅

PATCH  /api/v1/data/showcase_task/definitely_not_a_row   {"progress":1}
→ 200 {"object":"showcase_task","id":"definitely_not_a_row","record":null}          ❌

DELETE /api/v1/data/showcase_task/definitely_not_a_row
→ 200 {"object":"showcase_task","id":"definitely_not_a_row","success":true}         ❌

The REST layer is a pass-through (rest-server.ts DELETE handler res.json(await p.deleteData(...))), so the 200s come from the metadata-protocol's update/delete answering success on a zero-row match.

Why this matters beyond symmetry:

• A client that PATCHes a record which was concurrently deleted gets 200 with record: null and believes the write landed. Nothing in the envelope says "not found" — the caller has to null-check a success payload to detect a failed write.
• DELETE reports success: true for any string you put in the path — a typo'd id, an already-deleted row and a real deletion are indistinguishable. (The response also carries success where the spec's DeleteDataResponse declares deleted, so even the "did anything happen" bit the spec provides for is absent.)
• This is the exact shape the v17 train has been removing everywhere else this window: fix(data): sort / select / expand 指向不存在的字段时被拒绝，而不是静默丢弃 (#4226) #4240/fix(data): sort 的点号路径被拒绝（400 INVALID_SORT），不再静默降级为不排序 (#4256) #4303/fix(data): searchFields / groupBy / aggregations 指向不存在的字段时被拒绝，而不是静默降级 (#4254) #4315 (sort/select/expand/searchFields refuse missing fields), fix(data): reject unknown list query params instead of reading them as zero-matching filters (#4134) #4169 (unknown params refused), fix(data): implicit field filters AND-merge with an explicit filter instead of being silently dropped (#4164) #4190 (dropped filters now merge)… a write that touched zero rows reporting 200 is the same silent no-op, one level up.

Expected: PATCH/DELETE of a nonexistent id answer 404 RECORD_NOT_FOUND exactly as GET does (and a DELETE that does delete answers the declared deleted key). If idempotent-DELETE-200 is a deliberate posture, it should at least say deleted: false — but then PATCH, which has no idempotency story, still needs the 404.

Part of the #3909 rc.1 verification (section F3).

[baozhoutao]

Same family on the bulk path: POST /data/showcase_task/deleteMany {"ids":["nonexistent_1"]} → 200 {"succeeded":1,"failed":0,"results":[{"id":"nonexistent_1","success":true}]} — a batch of typo'd ids reports every one of them deleted.

[baozhoutao]

Tracked under the v17 verification tracker #3909 (section F, rc.1 run 1).

[baozhoutao]

Rolled up in #4482 (all 17 defects from the v17 verification, grouped by severity with a suggested RC-exit triage).