Cannons

The cannon document is an optional where you can specify:

  • where to source transactions from (ahead-of-time generated file or generate in realtime)
  • what kinds of transactions to generate
  • where to send transactions (to a file, or a node in the topology)

The cannon document is not required for a environment to run, but the document needs to be present at apply time to work.

This document is required if you want to use a cannon timeline action.

You can have more than one cannon per environment.

Fields

The different top level fields you can specify in a cannon document and what they mean. You can skip to examples by clicking here.

The required fields are italicized.

version

The version of the cannon document.

name

The name of the cannon document.

This is so you can refer to this cannon in other documents.

description

The optional description for a cannon document.

source

Where the transactions should come from.

query

Sets the query service for the cannon to use.

Has two modes local ledger or a node in the environment. Optional defaults to the local ledger.

local

An optional field that if provided uses the node in the environment specified to sync from.

Defaults to None, i.e. agent uses it's own local ledger as is.

source:
  query:
    sync-from: client/1 # optional
node

An optional field that if provided uses the node in the environment specified pulls that node's state root over RPC.

source:
  query: client/1 # required

compute

Sets the compute service for the cannon to use.

Has two modes agent or demox. Optional defaults to the agent.

agent

This tells the cannon to use agents in the environment.

You can optionally provide a list of agent labels to specify which agents to use.

source:
  compute:
    labels: foo,bar
demox

This tells the cannon to use Demox's API to generate the executions.

Requires the url for the API.

source:
  compute:
    demox-api: https://exampleurl.com/api/v1

sink

Sinks specify where transactions should go, and optionally how many attempts should be made before timing out.

file-name

Specify a file to write transactions to. This will reside inside the environment's data directory under this name.

sink:
  file-name: txs.json

The format of the file is:

{tx_1_info...}
{tx_2_info...}

target

Specify the node target(s) the tx's should be fired at.

sink:
  target: client/1

broadcast-attempts, broadcast-timeout, authorize-attempts, authorize-timeout

Options for configuring when to drop broadcast/authorization attempts.

The broadcast-* options are not relevant if target is not configured.

The broadcast-timeout and authorize-timeout options (seconds) start immediately after an attempt. A broadcast will not be re-broadcast/dropped until the next block occurs.

The broadcast-attempts and authorize-attempts are limitless when absent. A setting of 0 means a failure will not result in another attempt. A setting of 2 means two attempts will be made before dropping.

sink:
  target: '*/*'
  broadcast-attempts: 3
  authorize-attempts: 3
  broadcast-timeout: 60 # 1 minute timeout on failure
  authorize-timeout: 60 # 1 minute timeout on failure

Examples

A few different examples of topology docs.

Record txs to a file

---
version: cannon.snarkos.testing.monadic.us/v1

name: realtime-txs-record-to-file

source:
  query: "*/*" # node targets
  labels: [local] # compute labels

sink:
  file-name: txs.json

Playback Fire Right Away

---
version: cannon.snarkos.testing.monadic.us/v1

name: txs-from-file-to-target-node

source:
  # playback mode
  file-name: txs.json

sink:
  # realtime mode
  target: validator/test-1
  # 2 minute timeouts
  broadcast-timeout: 120
  authorize-timeout: 120
  # additionally record to a file
  file-name: out.json