fix: accept the spec's in-band posture for payment failure (drop 402/prose pin) - #77
Open
vishkaty wants to merge 1 commit into
Open
Conversation
Observed: test_payment_failure required HTTP 402 plus the English prose Payment Failed in the response body. The status code 402 appears nowhere in the 2026-04-08 specification, and the prose is the hardcoded mock string of the Flower Shop sample server (Payment Failed: Insufficient Funds (Mock)), not a spec requirement. Expected: payment_failed is a standard error message code (checkout.md error code table; error_code.json), and checkout-rest.md Error Responses prescribes that business outcomes return HTTP 200 with the UCP envelope and a typed messages[] entry. A conformant server that answers completion with HTTP 200 and a payment_failed error message failed this test with: Expected status 402, got 200. The fix routes the assertion through assert_business_error, the same dual posture helper already used by test_out_of_stock and test_structured_error_messages in this file: a 4xx rejection must describe the payment problem in its body, and a 2xx answer must carry a full typed error message with code payment_failed on a checkout that has not completed and carries no order. The relaxation stays sound: a server that neither rejects with a 4xx nor reports payment_failed in band, or that silently completes the checkout, still fails. Verified against both the Python and the Node reference servers (both suites green) and against stub servers implementing the in band posture and two genuinely broken behaviors.
damaz91
added
the
status:needs-triage
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Observed
test_payment_failure(validation_test.py) asserts the payment-failure response is HTTP 402 with the substring "Payment Failed". Both are stricter than the 2026-04-08 spec:payment_failedis a standard error message code (checkout.md error-code table;types/error_code.json), and checkout-rest.md ("Error Responses") states business outcomes "Return HTTP 200 with UCP envelope andmessagesarray." So a spec-conformant server returning 200 + amessages[]entry withcode: payment_failedfails this check.samples/rest/python/server/services/checkout_service.py: "Payment Failed: Insufficient Funds (Mock)"), not a spec-mandated message. Any conformant server with different wording fails.Fix
Use the file's own dual-posture helper
assert_business_error(response, accepted_codes={"payment_failed"}, error_4xx_substring="payment")— already used bytest_out_of_stockandtest_structured_error_messagesin the same file. This accepts either the in-band 200 +messages[code=payment_failed]posture or a payment-related 4xx, without pinning 402 or asserting sample prose.Verification
The relaxed check still catches a genuinely non-conformant server: a server that silently completes the checkout (200,
status: completed), returns a wrong/missing error code, a broken envelope, or a non-answer all still fail. The reference server's existing 402 posture still passes (no regression), andvalidation_test.pypasses on both the Python and Node references.