fix(openapi): align schemas with live API responses#2561
Conversation
The build list endpoint returns buildNumber, but it was missing from the BuildShort schema. As a result, generated clients (e.g. Pydantic models in apify-client-python) treated it as an undeclared extra field, exposing it only under the camelCase name and breaking the snake_case convention.
vdusek
added
t-tooling
|
✅ Preview for this PR (commit |
|
Important Action required — @vdusek please coordinate this docs PR with the Python API client PR linked below. Because this PR modifies the OpenAPI specification, the generated models in A companion PR has been opened in
|
| buildNumber: | ||
| type: string | ||
| examples: [0.1.1] |
There was a problem hiding this comment.
Doesn't this deserve a regex pattern, too? And maybe we could extract the type to a shared component (not sure about it though...)
…ests Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Important Action required — @vdusek please coordinate this docs PR with the Python API client PR linked below. Because this PR modifies the OpenAPI specification, the generated models in The companion
|
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
vdusek
changed the title
|
Important Action required — @vdusek please coordinate this docs PR with the Python API client PR linked below. Because this PR modifies the OpenAPI specification, the generated models in The companion
|
…s fields CI integration tests failed because: - the API returns sourceType=SOURCE_CODE which is not in VersionSourceType enum - DatasetStats list responses omit storageBytes (only inflatedBytes/readCount/writeCount are returned) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Important Action required — @vdusek please coordinate this docs PR with the Python API client PR linked below. Because this PR modifies the OpenAPI specification, the generated models in The companion
|
…okSummary - VersionSourceType: add SOURCE_CODE value the API actually returns (was producing literal_error in client validation) - WebhookDispatch.webhook: extract inline object to a top-level WebhookDispatchWebhookSummary schema so codegen doesn't synthesize a Webhook1 name that collides with the Webhook schema Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Important Action required — @vdusek please coordinate this docs PR with the Python API client PR linked below. Because this PR modifies the OpenAPI specification, the generated models in The companion
|
|
Important Action required — @vdusek please coordinate this docs PR with the Python API client PR linked below. Because this PR modifies the OpenAPI specification, the generated models in The companion
|
3 participants
Align OpenAPI schemas with what the live Apify API actually returns, so the generated
apify-client-pythonPydantic models declare every documented field. Originally reported as apify-client-python#811 forbuildNumberonBuildShort; broadened after running the Python integration suite with Pydanticextra='forbid'to surface the full gap across ~20 schemas (Actor, Build, KVS, Run, Schedule, Webhook, User plan/limits, store listings, …).