casework: model the review result payload rules as a status-tagged union in the published OpenAPI

Open
#1,203 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
openapi, python
Domain
api, backend-api-design

Research direction

Start in products/casework/scripts/generate_openapi.py at the ReviewResult entry and run the documented generator command. Inspect the committed OpenAPI document and client typings; done means status-discriminated branches consistently encode required payload presence across the generated document and three bindings without changing wire behavior. Coordinate with #1200 on the Python TypedDict typing.

Written by the indexing model from the issue text.

Description

Deferred from #1189 review (thread 4058174731).

The published ReviewResult schema (products/casework/scripts/generate_openapi.py, ReviewResult entry) declares outcome and result as unconditionally optional across all six statuses. The runtime never emits the invalid combinations: the settlement path binds outcome/result presence to the status (answered/rejected/changes_requested carry the outcome payload; approved/cancelled/superseded do not), and approval kinds cannot define answered outcomes at all. So the published contract is looser than the enforced one, and schema-conforming generated clients can type payloads the service will never send.

Tighten the publication by modeling the status-dependent variants as a closed union (for example oneOf branches discriminated by status with per-branch required fields), regenerate the committed OpenAPI document with its documented generator command, and align the client typings. Coordinate with #1200, which covers the Python TypedDict side of the same result typing.

Not merged with #1189 because the wire behavior is unchanged: this is a publication-accuracy improvement crossing the generated OpenAPI and three language bindings, better landed as its own reviewed change than as a late addition to an approval-ownership migration.

Dominant language
Rust
Stars
2
Forks
0
Avg merge
3h 45m
Merged PRs (30d)
134

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from registrystack/registry-stack

All issues in registrystack/registry-stack

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.