Why
We keep all the status and type values in contracts/schemas/enums.yaml, and app/api/schemas/enums.py is generated from it. But in a lot of places the code still compares plain strings instead of using those enums. If someone types "complete" instead of "completed" nothing complains.
Example, in the extraction route:
if provider.status == "unhealthy":
The health values are already an enum in the contract, we just never used them here.
What needs doing
This is not one line. The same pattern is spread across routes, services, workers and schemas. Job status, batch status, sort order and a few more all do the string thing. So the first job is to go through the codebase and list every place, then fix them together.
Where a value is missing from enums.yaml, it gets added there first and then regenerated. The sync check in generate_contract_models.py will fail otherwise.
Nothing changes on the wire. These are all str enums so the responses stay exactly the same.
Why
We keep all the status and type values in
contracts/schemas/enums.yaml, andapp/api/schemas/enums.pyis generated from it. But in a lot of places the code still compares plain strings instead of using those enums. If someone types"complete"instead of"completed"nothing complains.Example, in the extraction route:
The health values are already an enum in the contract, we just never used them here.
What needs doing
This is not one line. The same pattern is spread across routes, services, workers and schemas. Job status, batch status, sort order and a few more all do the string thing. So the first job is to go through the codebase and list every place, then fix them together.
Where a value is missing from
enums.yaml, it gets added there first and then regenerated. The sync check ingenerate_contract_models.pywill fail otherwise.Nothing changes on the wire. These are all
strenums so the responses stay exactly the same.