[Schema Inaccuracy] pull-request-review.state and two siblings should be enum, not string
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 70/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- openapi
- Domain
- api
Research direction
Start by locating the component schemas pull-request-review.state, timeline-reviewed-event.state, and webhooks_review.state, then compare them with the documented API values and the inline webhook-pull-request-review-dismissed.review.state precedent. Done means the REST schema lists the five uppercase values, while the timeline and shared webhook schemas list the four lowercase submitted-review values.
Written by the indexing model from the issue text.
Description
Schema Inaccuracy
Three schemas type their review state property as a plain string rather than an enum, even though the value is constrained to a documented set.
REST (uppercase values):
components/schemas/pull-request-review.state—{ "type": "string", "example": "CHANGES_REQUESTED" }. Used byGET /repos/{owner}/{repo}/pulls/{pull_number}/reviewsand every other endpoint returning a review.
Event records (lowercase values):
components/schemas/timeline-reviewed-event.state—{ "type": "string", "example": "CHANGES_REQUESTED" }. Returned byGET /repos/{owner}/{repo}/issues/{issue_number}/timeline. Theexamplevalue here is uppercase, but the live API returns lowercase for this surface (see Reproduction below).components/schemas/webhooks_review.state—{ "type": "string" },$ref'd fromwebhook-pull-request-review-submitted.reviewand-edited.review. Webhook payloads deliver lowercase.
The canonical value list is GitHub's own GraphQL PullRequestReviewState enum: APPROVED, CHANGES_REQUESTED, COMMENTED, DISMISSED, PENDING. Prior precedent for citing the GraphQL enum as the source of truth: #74 (author_association), which was resolved by introducing a shared author-association component schema with the enum drawn from the GraphQL CommentAuthorAssociation enum.
Expected
pull-request-review.state (REST) should enumerate the uppercase values the API returns:
"state": {
"type": "string",
"enum": ["APPROVED", "CHANGES_REQUESTED", "COMMENTED", "DISMISSED", "PENDING"],
"example": "CHANGES_REQUESTED"
}
timeline-reviewed-event.state and webhooks_review.state should enumerate the lowercase values these surfaces actually deliver (pending is omitted because reviews don't reach event records or webhook payloads until submitted):
"state": {
"type": "string",
"enum": ["approved", "changes_requested", "commented", "dismissed"]
}
The inline webhook-pull-request-review-dismissed.review.state already declares the enum ["dismissed", "approved", "changes_requested"] directly — precedent for the same fix on webhooks_review.state.
Reproduction Steps
REST pull-request-review.state returns uppercase:
$ curl -s -H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/kubernetes/kubernetes/pulls/90000/reviews \
| jq '[.[].state] | unique'
[
"APPROVED",
"CHANGES_REQUESTED",
"COMMENTED"
]
timeline-reviewed-event.state returns lowercase from the same PR (despite the spec's uppercase example: "CHANGES_REQUESTED"):
$ curl -s -H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/kubernetes/kubernetes/issues/90000/timeline \
| jq -r '[.[] | select(.event == "reviewed") | .state] | unique'
[
"approved",
"changes_requested",
"commented"
]
- Dominant language
- No language data
- Stars
- 1.6k
- Forks
- 342
- Avg merge
- 3h 33m
- Merged PRs (30d)
- 51
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/rest-api-description
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
github/rest-api-description#7201 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/rest-api-description#7163 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
github/rest-api-description#7162 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
github/rest-api-description#7135 ·
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
github/rest-api-description#7111 · 1 comment ·
All issues in github/rest-api-description
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
kubernetes-sigs/kueue#15937 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·