Skip to content

feat(api): generate and commit the API deployment OpenAPI spec - #2237

Draft
chandrasekharan-zipstack wants to merge 1 commit into
mainfrom
feat/docstudio-openapi-spec
Draft

feat(api): generate and commit the API deployment OpenAPI spec#2237
chandrasekharan-zipstack wants to merge 1 commit into
mainfrom
feat/docstudio-openapi-spec

Conversation

@chandrasekharan-zipstack

Copy link
Copy Markdown
Contributor

Why

The published Python clients (unstract-client) and the SDKs generated for them are built from an OpenAPI description of the API deployment execute / status endpoints. That description was being produced by a script living outside this repository, so a route, serializer or response change here could silently invalidate it — the breakage would surface later, in a client repo, against a spec nobody in this PR could see.

This moves generation in-repo and makes drift a test failure.

What

  • drf-spectacular added as a backend dependency; DEFAULT_SCHEMA_CLASS and SPECTACULAR_SETTINGS set in settings/base.py. Both are read only during schema generation — no request-time behaviour changes.
  • The schema annotation for DeploymentExecution now sits above the view in api_deployment_views.py. It exists because the introspected schema is wrong in ways that matter to a generated client: a bare FileField maps to format: uri (correct for output, wrong for a multipart upload), result: null while an execution is pending crashes a generated deserialiser without allow_null, and operation_id / tags decide the command names and module paths clients expose.
  • api_v2/deployment_spec_urls.py — a urlconf that mirrors the real mount. Generating against the included sub-urlconf drops the prefix and produces paths the server does not serve.
  • manage.py generate_docstudio_spec writes specs/docstudio-oss.json (sorted keys, so the committed file is a usable drift signal). --check fails instead of writing.
  • api_v2/tests/test_docstudio_spec.py regenerates and compares. It runs in the existing unit-backend group — no database, no new CI job, and no second copy of the env block.

Regenerating

Change a route, a serializer or the annotation, then in backend/:

uv run python manage.py generate_docstudio_spec

and commit the result. The test tells you this in its failure message.

Testing

658 passed, 1 skipped in the backend unit suite (the tier this lands in), including the two new spec tests. Verified the generated spec is byte-identical to what the external script produced, apart from the root tags array — clients had nowhere to read group descriptions from, which is the one deliberate addition.

🤖 Generated with Claude Code

https://claude.ai/code/session_014f9oEEYspPH4fmPULTnLkJ

The published Python clients and their generated SDKs are built from a spec of
the deployment execute/status endpoints, which until now was produced by a
script living outside this repo — so a route or serializer change here could
silently invalidate it.

The schema annotation for DeploymentExecution now lives next to the view, and
`manage.py generate_docstudio_spec` writes specs/docstudio-oss.json. A unit
test regenerates and compares, so drift fails in this repo's existing CI tier
rather than in a client repo, with no database or extra CI job needed.

The generated spec is unchanged from what the external script produced, apart
from a root `tags` array — clients had nowhere to read group descriptions from.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014f9oEEYspPH4fmPULTnLkJ
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant