Skip to content

Commit

Permalink
refactor: add flag to determine behaviour on failure of a nested inst…
Browse files Browse the repository at this point in the history
…ruction
  • Loading branch information
witgaw committed Sep 16, 2024
1 parent 9202db5 commit 87410f9
Showing 1 changed file with 4 additions and 1 deletion.
5 changes: 4 additions & 1 deletion protocol/0074-BTCH-batch-market-instructions.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,14 +26,17 @@ Overall, building the ability to handle batches of market instructions in a sing
- **Amendments**: this is a list (repeated field) of Amend Order instructions
- **Submissions**: this is a list (repeated field) of Submit Order instructions
- Additionally the batch may contain a single transaction to change the current margin mode. If this transaction fails, all later transactions within the batch (cancellations/amendments/submissions) for the market referred to in the update are Stopped for reason MARGIN_MODE_UPDATE_FAILED.
- Additionally the batch may contain a an optional `ON ERROR` parameter which determines the behaviour in case any instruction in the batch fails. The supporeted values should be either: `CONTINUE` or `STOP`. When `CONTINUE` is selected and an instruction within the batch fails the execution should move to the next instruction. When `STOP` is selected and an instruction within the batch fails the execution should stop an no other instructions should not be enacted. Default value should be `CONTINUE`.
- The total number of instructions across all three lists (i.e. sum of the lengths of the lists) must be less than or equal to the current value of the network parameter `network.spam_protection.max.batch.size`. The margin mode update transaction is not included in this limit.

### Processing a batch

- A batch is considered a single transaction, with a single transaction ID and a single timestamp applying to all instructions within it. Each instruction should be given a sub-identifier and index allowing it to be placed sequentially in the transaction (e.g. by consumers of the event stream). These identifiers must be sufficient for a user to determine which instruction within a batch any result (order updates, trades, errors, etc.) relates to.
- The batches must be processed in the order **all cancellations, then all amendments, any margin mode update, then all submissions**. This is to prevent gaming the system, and to prevent any order being modified by more than one action in the batch. Updating the margin mode after cancellations and amendments allows the party to have control of which orders are outstanding when the margin mode changes.
- When processing each list, the instructions within the list must be processed in the order they appear in the list (i.e. in the order prescribed by the submitter). (Notwithstanding that each list is processed in its entirety before moving onto the next list, in the order specified above).
- All instructions within each list must be validated as normal **at the time that the instruction is processed**. That is, instructions cannot be pre-validated as a batch. If a prior instruction, would create a state that would cause a later instruction to fail validation, the later instruction must fail validation (and vice verse). If validation fails, that instruction must be skipped and the subsequent instructions must still be processed. Any validation or other errors should be returned, as well as a reference to the instruction to which they relate, in the response.
- All instructions within each list must be validated as normal **at the time that the instruction is enacted**. That is, instructions cannot be pre-validated as a batch. If a prior instruction, would create a state that would cause a later instruction to fail validation, the later instruction must fail validation (and vice verse).

If validation fails, the execution of other instructions depends on the value specified for the `ON ERROR` parameter. Any validation or other errors should be returned, as well as a reference to the instruction to which they relate, in the response.
- Any errors encountered in processing an instruction after it passes validation must cause it to be skipped, and the errors, as well as the instruction to which they relate, must be available in the result of the transaction.

Check failure on line 40 in protocol/0074-BTCH-batch-market-instructions.md

View workflow job for this annotation

GitHub Actions / Markdownlint

Lists should be surrounded by blank lines [Context: "- Any errors encountered in pr..."]
- In addition to the usual validation and other errors that can occur in processing an instruction, the following also apply:
- Any second or subsequent Amend Order instruction for the same order ID within a single Batch Instruction transaction is an error
Expand Down

0 comments on commit 87410f9

Please sign in to comment.