What happens
At dcf6824, several tests assert a hard HTTP 400 when a checkout create references an out-of-stock or unknown item — validation_test.py's test_out_of_stock, test_product_not_found, and test_structured_error_messages.
Why this looks wrong
The v2026-04-08 spec models business-level failures as in-band error_response bodies / messages[] on the checkout resource (see source/schemas/shopping/types/error_response.json and the messages field on checkout.json): the request transported fine, the commerce operation cannot establish (or fully satisfy) the resource, and the server answers 200/201 with typed messages such as out_of_stock (severity recoverable) carrying RFC 9535 paths. A merchant implementing that model fails these tests even though agents receive strictly richer, spec-shaped information than a bare 400.
If both postures are meant to be permitted, the assertions should accept either a 4xx error_response or a 200/201 whose body carries the corresponding messages[] entry. If the hard-4xx posture is intended to be normative, it would be good to state that in the spec — today it does not appear to be.
Reproduction
Run validation_test.py at dcf6824 against a merchant server that answers an out-of-stock checkout create with 201 + messages: [{"type":"error","code":"out_of_stock","severity":"recoverable","path":"$.line_items[0]"}]:
AssertionError: 400 not found in [200, 201] : Expected status [400], got 201
(Related to the version-lag family in #52/#53 — these assertions predate the v2026-04-08 release. See also #54 for a similar status-code-vs-state assertion on cancel.)
What happens
At
dcf6824, several tests assert a hard HTTP 400 when a checkout create references an out-of-stock or unknown item —validation_test.py'stest_out_of_stock,test_product_not_found, andtest_structured_error_messages.Why this looks wrong
The v2026-04-08 spec models business-level failures as in-band
error_responsebodies /messages[]on the checkout resource (seesource/schemas/shopping/types/error_response.jsonand themessagesfield oncheckout.json): the request transported fine, the commerce operation cannot establish (or fully satisfy) the resource, and the server answers 200/201 with typed messages such asout_of_stock(severityrecoverable) carrying RFC 9535 paths. A merchant implementing that model fails these tests even though agents receive strictly richer, spec-shaped information than a bare 400.If both postures are meant to be permitted, the assertions should accept either a 4xx
error_responseor a 200/201 whose body carries the correspondingmessages[]entry. If the hard-4xx posture is intended to be normative, it would be good to state that in the spec — today it does not appear to be.Reproduction
Run
validation_test.pyatdcf6824against a merchant server that answers an out-of-stock checkout create with201+messages: [{"type":"error","code":"out_of_stock","severity":"recoverable","path":"$.line_items[0]"}]:(Related to the version-lag family in #52/#53 — these assertions predate the v2026-04-08 release. See also #54 for a similar status-code-vs-state assertion on cancel.)