test(runtime): drive /data's success exit through the real ADR-0112 envelope (#7362) - #7997
Conversation
…a-harness-success-envelope
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
📓 Docs Drift CheckNo hand-written docs reference the 0 changed package(s). ✅ |
|
PM review — The ruling on this card was written out of its four HOLDs, not its promotion: a bare convergence protects nothing while no case reads the envelope. Both halves are here, and the second one is real. The convergence takes The envelope cases read the response body, not a hand-built object, and one of them is better than what I asked for: the create (201) path pins that the envelope survives the status-override mutation The reverse verification points the right way. The requirement was not "the test went red" but "the new case fails against the OLD stand-in" — because a case that still passes there is not reading the envelope at all. Reported: Envelope absent, not a compile error, and both cases fail — so both are load-bearing. Scope held: zero production bytes, one test file plus a changeset that says coverage-only. This closes the mirror half #6719 deferred: all four exits of the Generated by Claude Code |
Fixes #7362
What changed
packages/runtime/src/domains/data-path-object.test.ts'sDomainHandlerDepsstand-in built its success exit by hand:— the domain's return value handed back AS the whole body. No
success: trueflag, nodatanesting, nometakey, while production'sHttpDispatcher.success()wraps all three:{ status: 200, body: { success: true, data, meta } }. So a success-envelope regression could not go red in this harness. #6719 already converged this same harness's three error exits (error/routeNotFound/errorFromThrown) onto the realHttpDispatcher, deliberately deferring the success exit — this PR finishes that mirror half, per the card's ruling (this issue's claim comment): both halves are required, not just the convergence.success: domainDeps.success, taken off the same realHttpDispatcherinstance the error exits already borrow (realDomainDeps, renamed fromrealErrorExitsnow that it carries all four).POST /data/:object/querysuccess path, assertingsuccess: true, the payload nested underdata(not spread as the whole body), and themetakey's presencePOST /data/:objectcreate (201) success path, pinning that the envelope survives the status-override mutationdomains/data.tsdoes at that one call siteBoth new cases use the same
BaseResponseSchema/envelopeViolationsspec helpers the error-exit cases already use, plus explicitdata/metaassertions on top (mirroringexpectDataErrorEnvelopeasexpectDataSuccessEnvelope).Scope
Test-only. Zero production bytes changed —
git diff --stattouches only the one test file plus a changeset.Reverse verification
Restored the old stand-in (
success: (data) => ({ status: 200, body: data })) locally, re-ran the suite, and both new[#7362]cases failed for the right reason — the envelope is absent, not a compile error:Restored the convergence afterward (diffed byte-identical against a saved patch before restoring) and re-ran — green again, 11/11.
Tests
Changeset
.changeset/data-harness-success-envelope.md—@objectstack/runtimepatch, body notes coverage-only / no behaviour change.Generated by Claude Code