# `CommitOptions.supersede`

> Contract 2.0.0 · package sha256 `a857eca95b35921109faf997094bb4192f12527d9d0fcd4be7e97f06425bad6e` · generated from `configurator-runtime.d.ts` by `services/onsite-scripter/scripts/build-contract-docs.mjs`; edit the source, not this file.

Property of [`CommitOptions`](CommitOptions.md) · inherited by [`WriteOptions`](WriteOptions.md), [`TransactionOptions`](TransactionOptions.md) · stable · since 2.0.0

```ts
supersede?: boolean;
```

While a transaction is open: roll it back (it resolves 'superseded'); the writes queued behind
it apply in call order, then this one, which supersedes an adjacent replacing write to its
target (spec section 6.1, O2c). Use it only on a write that re-derives everything the
open transaction writes, because it rolls back whichever transaction is open, not only yours
(to cancel only your own, abort its `signal`). With no transaction open it has no effect.
With [`expectRevision`](CommitOptions.expectRevision.md) on the same write, [`expectRevision`](CommitOptions.expectRevision.md) decides first: while a transaction is
open the write is refused 'busy' and nothing rolls back. A dry run's `supersede` rolls nothing
back: the dry run queues behind the open transaction.

**Default:** false (the write is queued behind the transaction and applies after it closes)

## Generic-API test (spec 3.1)

| Rule | Result |
| --- | --- |
| 1. Neutral name | pass: `supersede` names no product |
| 2. A precedent | pass: a correctness rule (rows `X1`) |
| 3. Two apps, or labs | pass: 15 apps (ledger: app-4fd23bc869, app-822bb9d6aa, app-8675b3225c, app-b362a81c85, app-bcb7ef21da, app-c1384707fc, app-e3b47169bc, app-e61a0b42ad and 7 more) |
| 4. The cheaper fix first | decided per need in Appendix B: rows `X1` at tier stable (a member only where no rule, data, asset or app code serves the need) |