feat: drive protocol_test version and capability asserts from conformance_input#58
Open
vishkaty wants to merge 3 commits into
Open
Conversation
…ance_input Implements the direction proposed in Universal-Commerce-Protocol#53: protocol_test hardcoded the spec version and the Flower Shop's exact capability roster, so a merchant server targeting any other release or shipping a legitimate capability subset failed discovery conformance despite being conformant. - test_discovery asserts the version and required capabilities declared in conformance_input.json (new keys: ucp_version, required_capabilities), extending the input-file precedent from Universal-Commerce-Protocol#13. Universal structural rules stay unconditional: versions must be date-based (YYYY-MM-DD) and every capability group name must parse as a reverse-domain name (the same rule already applied to payment handler group names). - test_version_negotiation uses the version the server advertises in discovery as the compatible header value, so the test self-updates across spec releases; the incompatible case keeps the obviously-future literal. - The Flower Shop input file declares 2026-04-08 and the five capabilities the sample ships, so CI coverage against the sample is unchanged. Validated against the samples Flower Shop (main): full 13-file suite results identical before and after; wrong ucp_version and a missing required capability each fail with a precise message; omitting the new keys degrades to structural-only validation as documented in the README.
damaz91
added
status:needs-triage
Class sweep after the assertion-side conversion: the same pinned release
literal survived on the request-construction side. Now driven by
conformance_input.json's ucp_version (with the previous literal as the
fallback):
- the ucp envelope version declared on checkout create requests
- the default mock payment handler's version
- the mock shopping agent profile (version fields and spec/schema URLs
via a {ucp_version} template placeholder, injected like {webhook_port})
Suite behavior is unchanged under the default input (same bytes); with a
doctored ucp_version the suite demonstrably sends/serves that version.
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
3 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.
Implements the direction @kbrackney proposed in #53 (credit to them for the analysis and the design — the input-file keys and the self-updating negotiation are their proposal):
protocol_test.pyhardcodes the spec version and the Flower Shop's exact capability roster, so a merchant targeting any other release, or shipping a legitimate capability subset, fails discovery conformance despite being conformant with the spec's server-selects negotiation model.What changed
test_discoveryasserts the version and required capabilities declared inconformance_input.json(new keysucp_version,required_capabilities), extending the input-file precedent from [Feat]: Decouple the tests from the hardcoded sample data to support custom server implementations #13. Universal structural rules stay unconditional: versions must be date-based (YYYY-MM-DD), and every capability group name must parse as aReverseDomainName— the same rule the test already applies to payment-handler group names.test_version_negotiationuses the version the server advertises in discovery as the compatible header value, so it self-updates across spec releases; the incompatible case keeps the obviously-future2099-01-01.2026-04-08and the sample's five capabilities, so CI coverage against the sample is byte-for-byte as strict as today.Validation
main, pipucp-sdk): results identical before and after the change (all OK).ucp_versionfails with "Unexpected UCP version in discovery doc"; an input requiring a capability the server doesn't declare fails with the missing set named; omitting both keys degrades to structural-only validation and passes.ruff checkandruff format --checkclean.No overlap with #51 (different input-file keys, different test files). Closes #53 if the maintainers agree with the direction.
Update (class sweep): after converting the assertion side, I re-checked the whole suite for the same pinned-release class on the request/fixture side and converted the three surviving sites (second commit): the
ucp.versiondeclared on checkout create requests, the default mock payment handler's version, and the mock shopping-agent profile (now a{ucp_version}template placeholder, injected the same way as{webhook_port}). All fall back to the previous literal whenconformance_input.jsondoesn't setucp_version, so default behavior is byte-identical; with a doctoreducp_versionthe suite demonstrably sends and serves that version. The deliberately-future2099-01-01incompatible-version probe is intentionally left as a literal.