# Out-of-Sequence Transactions



Overview [#overview]

Out-of-sequence ("OOS") transactions are a minority case but essential for real-world use cases. They refer to transactions that have been added to the head of the transaction stack (as all transactions must be, unless they are creating a new branch) with an `effectiveTime` earlier than the based-on transaction's `effectiveTime`.

The design of out-of-sequence transaction handling ensures that out-of-sequence transactions will have the same coverage details as if all transactions had been issued in-sequence. The history of the out-of-sequence transaction(s) is maintained as well.

<Callout>
  An `effectiveTime` may equal an earlier transaction's. In this case, the transaction with the earlier `createTime` will be processed first.
</Callout>

High-Level Approach [#high-level-approach]

There are several key points about out-of-sequence transactions:

* In the transaction stack, all sequences of transactions through a given base transaction (called that transaction's local stack) are in-sequence.
* To handle an out-of-sequence transaction, a special type called an aggregate transaction is used, because it needs to contain at least one reversal and two new transactions: the OOS change and the reapplication of the reversed transaction.
* Clients do not need to declare a transaction as out-of-sequence; the system will identify the situation, creating the aggregate transaction as needed.
* If an out-of-sequence transaction were to be invalidated rather than issued, all that is needed is to mark it as invalidated and it will become effectively nullified. No other significant updates to the policy data are needed because the transaction contains the key details about the changes, and no other transactions are modified.

Static Locators [#static-locators]

When a transaction with locator X is reversed and then reapplied with transaction Y, transaction Y will have `locator` Y and `staticLocator` X. Note that for any local transaction stack, each transaction's `staticLocator` will be unique even though they may be duplicated in the overall stack.

Intervening Out-of-Sequence Transactions [#intervening-out-of-sequence-transactions]

When an out-of-sequence transaction needs to contain reapplication transactions from other transactions contained within aggregate transactions, it will create reapplication transactions that are not nested. For example, suppose we have this series of transactions in the local stack for transaction C:

`A` → `B`: (`B1` → `B2`) → `C`

Here, transaction `B` is an aggregate that contains `B1` and `B2`. If we try to create a new transaction `D` that's effective between `B1` and `B2`, we'd end up with:

`A` → `D`: (`D1` → `D2` → `D3` → `D4`)

So now aggregate transaction `D` contains:

* Transactions B1, B2, and C in its `reverses` array
* `D1`: the reapplication of `B1`
* `D2`: the new OOS change
* `D3`: the reapplication of `B2`
* `D4`: the reapplication of `C`

In this example, the fact that `D1` and `D3` were once part of an aggregate transaction is not retained in the local stack, though that fact is knowable by looking at transaction `B` directly.

Reversals [#reversals]

Issued out-of-sequence changes can themselves be reversed, like any other transaction, aggregate or not (except for the original Policy Issuance).

This is done by applying a new Reversal transaction that reverses the aggregate, and that makes the policy data identical to the state before the aggregate.

See Also [#see-also]

* [Transaction Branching and Invalidation](/features/policy-management/transaction-branching-and-invalidation)
* [The Policy Transaction stack](/features/policy-management/policy-transaction-stack)