Schema Inaccuracy
The current api.github.com OpenAPI descriptions for both 2022-11-28 and 2026-03-10 omit format: int64 from these ID parameters:
#/components/parameters/workflow-run-check-suite-id/schema
#/components/parameters/check-run-id/schema
#/components/parameters/job-id/schema
They are used by operations such as:
GET /repos/{owner}/{repo}/actions/runs?check_suite_id=...
GET /repos/{owner}/{repo}/check-runs/{check_run_id}/annotations
GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs
These parameters consume IDs returned by the same API. In particular, the Check Run and Check Suite response schemas already describe their IDs as int64, while the corresponding request parameters remain unformatted integer. Workflow Run and Job schemas have similar missing formats.
This causes generated clients to expose narrower parameter types than the IDs they may receive. For example, Octokit now represents fields explicitly marked int64 as number | bigint, but these request parameters are still generated as number.
This is related to, but does not duplicate, the existing Workflow Run run-id reports #4511 and #5733, and the Check Suite response schema report #4076.
Expected
The parameters above should declare:
{
"type": "integer",
"format": "int64"
}
The corresponding Workflow Run and Job response ID fields should also use format: int64 where they represent the same IDs.
Reproduction Steps
- Download either current versioned description:
curl -O https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.2026-03-10.json
- Inspect the affected parameter schemas:
jq '.components.parameters["workflow-run-check-suite-id"], .components.parameters["check-run-id"], .components.parameters["job-id"]' api.github.com.2026-03-10.json
- Each parameter is currently
type: integer without format: int64. Generate a client from the description and compare those request parameter types with response IDs that are already marked int64.
Schema Inaccuracy
The current
api.github.comOpenAPI descriptions for both2022-11-28and2026-03-10omitformat: int64from these ID parameters:#/components/parameters/workflow-run-check-suite-id/schema#/components/parameters/check-run-id/schema#/components/parameters/job-id/schemaThey are used by operations such as:
GET /repos/{owner}/{repo}/actions/runs?check_suite_id=...GET /repos/{owner}/{repo}/check-runs/{check_run_id}/annotationsGET /repos/{owner}/{repo}/actions/jobs/{job_id}/logsThese parameters consume IDs returned by the same API. In particular, the Check Run and Check Suite response schemas already describe their IDs as
int64, while the corresponding request parameters remain unformattedinteger. Workflow Run and Job schemas have similar missing formats.This causes generated clients to expose narrower parameter types than the IDs they may receive. For example, Octokit now represents fields explicitly marked
int64asnumber | bigint, but these request parameters are still generated asnumber.This is related to, but does not duplicate, the existing Workflow Run
run-idreports #4511 and #5733, and the Check Suite response schema report #4076.Expected
The parameters above should declare:
{ "type": "integer", "format": "int64" }The corresponding Workflow Run and Job response ID fields should also use
format: int64where they represent the same IDs.Reproduction Steps
jq '.components.parameters["workflow-run-check-suite-id"], .components.parameters["check-run-id"], .components.parameters["job-id"]' api.github.com.2026-03-10.jsontype: integerwithoutformat: int64. Generate a client from the description and compare those request parameter types with response IDs that are already markedint64.