get_action_traces

discontinued

Retrieve a stream of executed actions, filtered by receiver and account

Usage

Example request:

{
  "type": "get_action_traces",
  "listen": true,
  "req_id": "your-request-id",
  "irreversible_only": true,
  "data": {
    "accounts": "eosio.token",
    "action_name": "transfer",
    "with_inline_traces": true,
    "with_dbops": true,
    "with_dtrxops": true,
    "with_ramops": true
  }
}

Information about receiver, account and action_name

Actions on the EOS blockchain are identified by a triplet receiver/account/action_name

• The code on the receiver is called with the method account/action_name
• An action is considered a “notification” when the receiver is different from the account field. That receiver may or may not contain instructions to run for that account/action_name pair (more details ).

Arguments

Responses

• fetch: true is not supported for get_action_traces
• listen: true requests will stream ActionTrace objects.
• irreversible_only: true ensure that you only get actions from irreversible blocks. If you call it with start_block: (current head block), you will have to wait until that block becomes irreversible before you see any data streaming back.

Conversion to GraphQL API

Migrating to our GraphQL Search API is really easy and offers advantages that you really want to leverage to greatly improve your users experience. Converting to GraphQL Search API is simply a matter of crafting an equivalent search query and convert a fraction of your code to use the new format.

Assuming the following stream request message you would have used previously

{
  "type": "get_action_traces",
  "listen": true,
  "req_id": "your-request-id",
  "data": {
    "accounts": "eosio.token|tethertether",
    "action_names": "transfer|issue",
    "with_dbops": true,
    "with_dtrxops": true,
    "with_ramops": true
  }
}

That would result in the following GraphQL document:

subscription ($cursor: String) {
  searchTransactionsForward(
    query: "(account:eosio.token OR account:thetertheter) (action:transfer OR action:issue)",
    cursor: $cursor
  ) {
    undo cursor
    block { num id }
    trace {
      id
      matchingActions {
        seq
        receiver account name
        json
        dbOps { operation oldJSON { object error } newJSON { object error } }
        dtrxOps { operation payer transaction { actions { account name json } } }
        ramOps { operation delta usage }
      }
    }
  }
}

The "accounts": "eosio.token|tethertether" argument in get_action_traces becomes the (account:eosio.token OR account:thetertheter) clause while the "action_names": "transfer|issue" argument becomes the (action:transfer OR action:issue) clause, both of them separated by a space which acts as a logical AND.

With this document in hand, if you are using our JavaScript client library, updating is simple a matter of changing a single line:

// Instead of
const stream = await client.streamActionTraces(..., (message) => { ... })

// Use
const stream = await client.graphql(document, (message) => { ... })

The logic changes a bit between the two calls also. While the streamActionTraces call generates one message per action, the GraphQL version generates one message per matching transaction, a transaction containing actions and you can easily find those the matched the query using the matchingActions field.

To use the same logic as before in GraphQL, you will need, for each message received, to loop through matchingActions (pseudo-code example below, logic applies to all languages):

for action in message.searchTransactionsForward.trace.matchingActions:
  // Do your old `get_action_traces` on message logic here

The message format you will receive has also change, but making the necessary adjustments is trivial. This is especially true since in GraphQL, you have the power to pick and choose the exact field you want to receive drastically shaving bandwidth cost in most usual cases.

We will not provide a 1 to 1 mapping list as it would be too much. You can use the GraphiQL Online Editor , link and start from there, then slowly add (or remove) the fields you interested in.

Finally, if you were using some of the more advanced WebSocket fields, here is how to convert them.

Field "irreversible_only": true

Add irreversibleOnly: true parameter below cursor parameter in GraphQL document:

subscription ($cursor: String) {
  searchTransactionsForward(
    ...
    cursor: $cursor,
    irreversibleOnly: true
  ) { ... }
}

Field "with_progress": 15

Add liveMarkerInterval: 15 parameter below cursor parameter in GraphQL document:

subscription ($cursor: String) {
  searchTransactionsForward(
    ...
    cursor: $cursor,
    liveMarkerInterval: 15
  ) { ... }
}

Field "start_block": -350

Add lowBlockNum: -350 (or a direct block num) parameter below cursor parameter in GraphQL document:

subscription ($cursor: String) {
  searchTransactionsForward(
    ...
    cursor: $cursor,
    lowBlockNum: -350
  ) { ... }
}

const stream = await client.graphql(document, (message) => {
  if (message.type === "data") {
    // Procesing here

    stream.mark({ cursor: message.data.searchTransactionsForward.cursor })
  }
})

Next Steps

You can use the following links to complete your code conversion to GraphQL:

• If using the JavaScript client library, checkout the Quick Start: JavaScript - Stream your first results section.
• For other languages, refers to Quick Start: Other Languages to learn how to make a GraphQL stream using your language of choice.