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

Schema

• request_type string

  Possible values: [advance_state, inspect_state]

• data object

  oneOf

  MOD1

  metadata object

  msg_sender string

  epoch_index uint64

  input_index uint64

  block_number uint64

  timestamp uint64

  payload string

  MOD2

  payload string

Example (from schema)

{
  "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.

Loading...