failure.duplicate_code

Two failures have the same code, or a failure has a code the runtime already answers with itself.

Area 4, Failures; not declinable; the next step is usually the human's.

Why Jadpo refuses it

A failure's code is what a client reads to tell failures apart. It comes from the failure's name in lower_snake_case, CustomerNotFound is customer_not_found, unless code: gives another. A client relies on a code always meaning the same failure, with the same status, message and fields. Two failures with one code would make it mean either, so every code belongs to one failure.

Jadpo won't choose the fix for you. Clients already rely on the codes you send, and only you know whether the two failures are one, and which of them keeps the code.

What it looks like

main.jadpo:

type CustomerNotFound = Failure {    kind: FailureKind.not_found    message: "Customer not found."}type CustomerMissing = Failure {    kind: FailureKind.not_found    code: "customer_not_found"    message: "Customer not found."}

  |8 |     code: "customer_not_found"  |           ^^^^^^^^^^^^^^^^^^^^ the same code

(human) at the end of the next: line tells your coding agent to stop and ask you which fix you want, because the choice is yours to make: it decides which failure each code your clients see stands for.

The runtime answers some requests with codes of its own, such as invalid_input for request input that breaks a rule, so no failure may take them: invalid_input, invalid_request, route_not_found, deadline_exceeded, transaction_unavailable, read_unavailable, outcome_unknown and internal_fault. A failure whose name gives one of these codes is the same error:

main.jadpo:

type InvalidInput = Failure {    kind: FailureKind.invalid_value}

  |1 | type InvalidInput = Failure {  |      ^^^^^^^^^^^^ a runtime code

How to fix it

The question is whether the two failures mean the same thing to a client.

If they are one failure, keep one and use it everywhere the other was rejected. main.jadpo becomes:

type CustomerNotFound = Failure {    kind: FailureKind.not_found    message: "Customer not found."}

Every missing customer now reaches the client as customer_not_found, whichever action rejects it.

If they are different failures, remove the code: line, so CustomerMissing takes the code its name gives. main.jadpo becomes:

type CustomerNotFound = Failure {    kind: FailureKind.not_found    message: "Customer not found."}type CustomerMissing = Failure {    kind: FailureKind.not_found    message: "Customer not found."}

Clients get customer_not_found for one and customer_missing for the other. A client that read customer_not_found for both now sees a new code for CustomerMissing, and changing a public code is a breaking change (What the client sees).

If a failure's name gives a runtime code, rename the failure:

type EntryInvalid = Failure {    ...}

Its code is now entry_invalid, which a client can tell apart from the runtime's invalid_input. Use code: instead only to keep a code clients already rely on after a rename (The code clients see).

Related

• The code clients see
• Declaring a failure
• What the client sees