A translation layer between internal exceptions and HTTP status codes.
In progress, assigned, and blocked on review. The design document and the implementation disagree in three places, which is what the reviewer flagged.
The ingestion API raises domain exceptions and lets them propagate. The framework turns anything unhandled into a 500, so a malformed payload and a dead database are indistinguishable to a caller, and both page whoever is on call.
The proposal is a single mapping registry: each domain exception declares its status code, whether it is retryable, and what the caller is told. Everything unmapped stays a 500, deliberately, so adding an exception without a decision does not silently become a 400.
Scattered handling is how the current inconsistency happened. A single table can be reviewed in one sitting.
The default has to be the pessimistic one. A new exception defaulting to 400 would tell callers not to retry something they should.
Clients need to know whether to back off. That is a property of the failure, not of the status code alone.
What this brief could not check
- This brief was written by hand as a design fixture. It is modelled on real work, but no model read a diff to produce it, and its claims should not be relied on.
- The linked design document was not read; the three disagreements are described from the review comment that lists them.
- Whether ingestion is idempotent could not be determined from the ticket, and it decides the timeout question.