data.conflict_unmapped

A write could be refused by a unique rule or a reference, and its conflict: block doesn't say which failure the caller gets then.

Area 6, Reads and writes; not declinable; the next step is usually the agent's.

Why Jadpo refuses it

Jadpo knows which rules each write can break. A create can break every unique rule of its entity, and a delete can be blocked by a restricted reference to the record. When one does, the caller needs a failure it can handle, such as "that email is already registered", rather than the database's own error.

There is no catch-all, because each rule means something different to the caller. So each rule the write can break needs its own arm in conflict:, naming a failure of kind conflict.

What it looks like

main.jadpo:

entity Customer {    id: Uuid    email: Email {        unique: true    }}action register(email: Customer.email) -> Customer {    return Customer.create {        set: {            email: email        }    }}

  |9 |     return Customer.create {  |            ^^^^^^^^^^^^^^^ can be refused

(agent) at the end of the next: line means your coding agent can make the fix itself.

How to fix it

If the write can clash with an existing record, declare a failure of kind conflict, map the rule to it in conflict:, and pass it on with attempt, saying in fails that the action can fail with it:

type EmailTaken = Failure {    kind: FailureKind.conflict}action register(email: Customer.email) fails EmailTaken -> Customer {    return attempt Customer.create {        set: {            email: email        }        conflict: {            Customer.email: EmailTaken        }    }}

Registering an email that another customer already has now fails with EmailTaken, and a client calling it through a route gets a 409, the status of its kind, conflict.

Related

• When a write is refused
• A write that breaks a unique rule: conflict:
• Failure kinds
• data.conflict_cannot_break