Skip to content

fix(spec): correct enum values in validation error example #1641

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
matanweks wants to merge 1 commit into
base: main
Choose a base branch
from
+1 −1
Open

fix(spec): correct enum values in validation error example #1641

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1584,7 +1584,7 @@ Content-Type: application/problem+json
},
{
"field": "status",
"message": "Invalid status value 'running'. Must be one of: pending, working, completed, failed, canceled"
"message": "Invalid status value 'TASK_STATE_RUNNING'. Must be one of: TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, TASK_STATE_INPUT_REQUIRED, TASK_STATE_REJECTED, TASK_STATE_AUTH_REQUIRED"
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Mar 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

While this change correctly updates the enum values, the overall structure of this error example seems inconsistent with the error handling specification for the HTTP+JSON binding.

  • Section 11.6 specifies that HTTP error responses should follow the AIP-193 format, which uses a top-level error object.
  • This example (and the one in Section 6.4) appears to follow RFC 7807 Problem Details, as indicated by the Content-Type: application/problem+json header.

This creates a contradiction within the specification. To ensure clarity and consistency for implementers, it would be beneficial to align all HTTP error examples with the single format defined as normative in Section 11.6. This would likely require refactoring this entire error response example in a separate change.

}
]
}
Expand Down
Loading