# precondition-violated

A **[precondition](/docs/eventsourcingdb/preconditions)** of a write **does not hold**, so **none of its events were written**.

- **Route:** `write-events`
- **Description:** `/preconditions/<index>: precondition <type> does not hold`, with the place of the precondition in its list, counting from 0, and its type
- **Details:** **`precondition`**, the place of the precondition in its list, counting from 0.

## Why It Happens

The state of the database is not the one the write expects: a subject that is meant to be pristine has events, one that is meant to be populated has none, the latest event of a subject is not the one the write names, or an `isEventQlQueryTrue` query returns `false`. Usually, **another client wrote in the meantime**, after your code read the state it decided on.

If several preconditions do not hold, the error names the first of them. The preconditions on subjects are checked in the order of the request, and every `isEventQlQueryTrue` precondition after them, since its query may read every event.

## How to Fix It

Read the state again, decide again, and write with the preconditions that the new state calls for. Do not resend the same request unchanged: it succeeds only once the precondition holds again, which for `isSubjectOnEventId` it never does.

## Example

For a write whose second precondition expects `/books/42` to be on the event `23`, while another event has been written to it since, EventSourcingDB answers with this error, as a line of the stream, and then ends the stream with its `end` item:

```json
{
  "type": "error",
  "data": {
    "code": "https://docs.eventsourcingdb.io/errors/precondition-violated",
    "description": "/preconditions/1: precondition isSubjectOnEventId does not hold",
    "details": {
      "precondition": 1
    }
  }
}
```