Finish and get next request

The DApp backend should call this method to start processing rollup requests. The Rollup HTTP Server returns the next rollup request in the response body.

The possible values for the request_type field are 'advance_state' and 'inspect_state'. The data field contains the rollup request input data. For advance-state requests, the input data contains the advance-state metadata and the payload. For inspect-state requests, the input data contains only the payload.

After processing a rollup request, the DApp back-end should call again the finish method. For advance-state requests, depending on the result of the request processing, it should fill the status field of the request body with 'accept' or 'reject'. The Rollup HTTP Server ignores the content of the status field for the first finish request and after an inspect-state request.

If the advance-state request is rejected, the vouchers and notices are discarded. In contrast, reports are not discarded in case of rejection. When running inside a Cartesi machine, the Cartesi Server Manager reverts the entire state of the machine to what it was before receiving the request.

During a finish call, the next rollup request might not be immediately available. When the DApp backend and the Rollup HTTP Server are running inside a Cartesi machine, the Cartesi Server Manager pauses the whole machine execution until the next request is ready. When running in host mode, the Rollup HTTP Server returns the status code 202 after 10 seconds to avoid the connection timing out. When the Rollup HTTP Server returns 202, the DApp backend should retry the call to finish passing the same arguments as before.

application/json

Request Body

• status string

  Possible values: [accept, reject]

Responses

• 200
• 202
• default

---

Finish accepted and next rollup request returned.

application/json

• Schema
• Example (from schema)

---

Schema

• request_type string

  Possible values: [advance_state, inspect_state]

• data object

  oneOf

  • MOD1
  • MOD2

  ---

  metadata object

  msg_sender string

  20-byte address of the account that submitted the input.

  epoch_index uint64

  Deprecated. Always receives 0.

  input_index uint64

  Input index starting from genesis.

  block_number uint64

  Block number when input was posted.

  timestamp uint64

  Unix timestamp of block in milliseconds.

  payload string

  The payload is in the Ethereum hex binary format. The first two characters are '0x' followed by pairs of hexadecimal numbers that correspond to one byte. For instance, '0xdeadbeef' corresponds to a payload with length 4 and bytes 222, 173, 190, 175. An empty payload is represented by the string '0x'.

  payload string

  The payload is in the Ethereum hex binary format. The first two characters are '0x' followed by pairs of hexadecimal numbers that correspond to one byte. For instance, '0xdeadbeef' corresponds to a payload with length 4 and bytes 222, 173, 190, 175. An empty payload is represented by the string '0x'.

{
  "request_type": "advance_state",
  "data": {
    "metadata": {
      "msg_sender": "string",
      "epoch_index": 0,
      "input_index": 0,
      "block_number": 0,
      "timestamp": 0
    },
    "payload": "string"
  }
}

Finish accepted but try again to obtain the next request.

Error response.

text/plain

• Schema

---

Schema

• string

  Detailed error message.