Skip to content

fix(ucp): constrain resource responses to success status - #747

Open
pranshu-10 wants to merge 4 commits into
Universal-Commerce-Protocol:mainfrom
pranshu-10:fix/resource-response-success-status
Open

fix(ucp): constrain resource responses to success status#747
pranshu-10 wants to merge 4 commits into
Universal-Commerce-Protocol:mainfrom
pranshu-10:fix/resource-response-success-status

Conversation

@pranshu-10

@pranshu-10 pranshu-10 commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Description

  • Normal Checkout, Cart, Order, and Catalog response schemas inherit the base ucp.status definition, which permits both success and error.

  • As a result, a resource-shaped response can incorrectly validate with ucp.status: "error", even though the specification defines:

    • success as carrying the expected resource payload.
    • error as carrying error information instead of a resource.
  • This change constrains status to success in the four normal resource
    response schemas:

    • response_checkout_schema
    • response_order_schema
    • response_cart_schema
    • response_catalog_schema
  • The field remains optional, so responses that omit status continue to validate. The existing default: "success" documents the default semantics but does not insert the field during JSON Schema validation.

  • The separate error-response schema continues to require ucp.status: "error".

  • This is a breaking schema tightening because resource-shaped responses that explicitly use ucp.status: "error" were previously accepted and will now be rejected.

    Category (Required)

    • Core Protocol: Changes to the base communication layer, global context, or breaking refactors. (Requires Technical Council approval)
    • Governance/Contributing: Updates to GOVERNANCE.md, CONTRIBUTING.md, or CODEOWNERS. (Requires Governance Council approval)
    • Capability: New schemas (Discovery, Cart, etc.) or extensions. (Requires Maintainer approval)
    • Documentation: Updates to README, or documentations regarding schema or capabilities. (Requires Maintainer approval)
    • Infrastructure: CI/CD, Linters, or build scripts. (Requires DevOps Maintainer approval)
    • Maintenance: Version bumps, lockfile updates, or minor bug fixes. (Requires DevOps Maintainer approval)
    • SDK: Language-specific SDK updates and releases. (Requires DevOps Maintainer approval)
    • Samples / Conformance: Maintaining samples and the conformance suite. (Requires Maintainer approval)
    • UCP Schema: Changes to the ucp-schema tool (resolver, linter, validator). (Requires Maintainer approval)
    • Community Health (.github): Updates to templates, workflows, or org-level configs. (Requires DevOps Maintainer approval)

    Related Issues

    No related issue.

    Checklist

    • I have followed the Contributing Guide (including Conventional Commits title requirements and
      ! for breaking changes).
    • I have updated the documentation (not applicable; this change enforces the existing documented response semantics).
    • My changes pass all local linting and formatting checks.
    • I have added tests that prove my fix is effective or that my feature works.
    • New and existing unit tests pass locally with my changes.
    • (For Core/Capability) I have included/updated the relevant JSON schemas.
    • I have regenerated Python Pydantic models by running generate_models.sh under python_sdk.

    Screenshots / Logs (if applicable)

The following validations were run locally on this branch:

  1. Schema lint
    ucp-schema lint source/

  2. Example validation
    uv run --frozen python scripts/validate_examples.py --schema-base source/schemas/

  3. Validator unit tests
    uv run --frozen python scripts/test_validate_examples.py

  4. Targeted schema behavior
    A temporary local validation script checked all four affected response schemas:

             Test case                       Before      After

          Resource with status: "success"     Valid      Valid
 
          Resource with omitted status        Valid      Valid

          Resource with status: "error"       Valid    Invalid

          Proper error response               Valid      Valid

@pranshu-10
pranshu-10 marked this pull request as ready for review August 18, 2026 18:29
@damaz91 damaz91 added the status:needs-triage Signal that the PR is ready for human triage label Aug 18, 2026
@carolinerg1 carolinerg1 added status:under-review gov:needs-gc-review Requires review and approval from the Governance Council and removed status:needs-triage Signal that the PR is ready for human triage labels Aug 19, 2026
@carolinerg1 carolinerg1 self-assigned this Aug 19, 2026
@carolinerg1 carolinerg1 removed their assignment Sep 4, 2026
@damaz91 damaz91 added status:stale-review Applied if a PR is waiting on a reviewer for too long and removed status:under-review labels Sep 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gov:needs-gc-review Requires review and approval from the Governance Council status:stale-review Applied if a PR is waiting on a reviewer for too long

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants