data.conflict_cannot_break

A write's conflict: block maps a rule that the write can never break.

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. An update can break only the unique rules over the fields it sets. Here Customer.update sets name and not email, so the unique rule on email can never refuse it, and its arm in conflict: never runs.

An arm that never runs misleads the reader, and the failure it names makes callers handle something that can't happen. Usually it means the write changed and the arm was left behind.

What it looks like

main.jadpo:

type CustomerName = Text {    max_length: 80}entity Customer {    id: Uuid    email: Email {        unique: true    }    name: CustomerName}type EmailTaken = Failure {    kind: FailureKind.conflict}action rename(customer: Customer, name: Customer.name) fails EmailTaken -> Customer {    return attempt Customer.update(customer) {        set: {            name: name        }        conflict: {            Customer.email: EmailTaken        }    }}

   |23 |             Customer.email: EmailTaken   |             ^^^^^^^^^^^^^^ never runs

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

How to fix it

If the write isn't meant to change the email, remove the arm. With it goes the conflict: block, EmailTaken, and the fails and attempt that only passed that failure on:

action rename(customer: Customer, name: Customer.name) -> Customer {    return Customer.update(customer) {        set: {            name: name        }    }}

rename now declares no failure, so its callers no longer handle an EmailTaken that could never happen.

Related

• When a write is refused
• A write that breaks a unique rule: conflict:
• data.conflict_unmapped
• failure.mapping_kind
• failure.duplicate_mapping