croncats / query-indexer Goto Github PK

For now we can use this:
https://jsfiddle.net/beaver71/2j2gk8nb/

Where you can edit the data for the two charts. The data for the two charts has the similar x: …, y: … that we're outputting here.

Let's please create a chart that shows two lines:

1. One representing a task (paying three people, for instance) and the total balance (this should be going down)
2. One representing the agent's native and manager state balance

Create a task, give it 1 JUNO. Make sure the agent has enough JUNO so complete all the recurring payments (without having to stop and call withdraw)

Then at the end, when the task has completed, stop the agent and call withdraw.

At this point the indexer will have enough data to put into the JSFiddle link above.

And if you could please run that test on tasks that are Once and and Immediate.

I have been using this script that does payments every other block:

recurring payment simple script.zip

(Note, in the zip file above I do not have scripts for Once and Immediate, so if you can please write those it'd be great)

The most important thing we need to know: what percentage did the agent end up making in all the tests? How does this compare to our expectations?

If we could have a report of that, it'd be amazing, thank you

So far, we have only one ExpressJS route, shown here:

There is a lot more you can do with routes, especially when you give parameters:
https://expressjs.com/en/guide/routing.html#route-parameters

The page above shows an example that looks like this:

app.get('/users/:userId/books/:bookId', (req, res) => {
  res.send(req.params)
})

We'll want to do something similar for this ticket, but instead of :userId and :bookId we will have one parameter :txHash.

Let's talk a bit about how this is working on the smart contract level, and then how that translates to what's stored in the database by the Indexer Sweeper. (this repo: https://github.com/CronCats/indexer-sweep)

Someone can query the CronCat Manager smart contract method get_task and give the hash as a parameter. That will eventually lead to a function that returns this struct:

pub struct TaskResponse {
    pub task_hash: String,

    pub owner_id: Addr,

    pub interval: Interval,
    pub boundary: Option<Boundary>,

    pub stop_on_fail: bool,
    pub total_deposit: Vec<Coin>, // ✨✨✨ THIS IS THE FIELD WE'RE CONCERNED WITH IN THIS TICKET ✨✨✨
    pub total_cw20_deposit: Vec<Cw20CoinVerified>,
    pub amount_for_one_task_native: Vec<Coin>,
    pub amount_for_one_task_cw20: Vec<Cw20CoinVerified>,

    pub actions: Vec<Action>,
    pub rules: Option<Vec<CroncatQuery>>,
}

When it comes to the Indexer Sweeper, this field is saved here:

https://github.com/CronCats/indexer-sweep/blob/39bb496e2d8818a8ccdc3d853a67f663fe31cfef/src/entities/tasks/tasks.ts#L105-L117

(Since it's not showing a preview, I'll paste it as well)

// Total deposits (total_deposit)
// NOTE: at the time of this writing, it seems like we're just covering native token
// but the database table task_deposits will be able to have other types
for (const totalDepositNative of task.total_deposit) {
    promises.push(
        db('js_task_deposits').insert({
            fk_task_id: taskFkId,
            type: 'native',
            denom: totalDepositNative.denom,
            amount: totalDepositNative.amount
        })
    )
}

So this is in the js_task_deposits table and looks like this:

So the ExpressJS route will probably look like this, but I am open to you modifying after digging into this ticket, of course:

app.get('/task/:taskHash/deposits', (req, res) => {
  // …
})

That will lead to a query that uses similar logic to the existing one in this repo:
https://github.com/CronCats/query-indexer/blob/main/src/queries/tx.ts#L8-L13

but will return all the deposits for that particular task.

NOTE! As I have been writing this ticket, I am seeing something odd, which you can see in the screenshot from Postico showing the Postgres database. It looks like fk_task_id is an incrementing number, when I would expect that the foreign key would not appear like that. I would expect Task 1 to have a foreign key of 1 in this table, and to see 1 multiple times as the total_deposit decreases from the agent calling. I will look into this.

I believe this is enough information, however, to get going on this task))

Let's add a query that'll display the protocol level balance and the balance owed to the agent (they get these tokens with the agent withdraws)

On the smart contract level, the response to get_agent (providing the account_id of the agent) method is:

pub struct AgentResponse {
    // This field doesn't exist in the Agent struct and is the only one that differs
    pub status: AgentStatus,
    pub payable_account_id: Addr,
    pub balance: GenericBalance, // ✨✨✨ THIS IS THE MOST IMPORTANT FIELD WE'RE CONCERNED WITH IN THIS TICKET ✨✨✨
    pub total_tasks_executed: u64,
    pub last_executed_slot: u64,
    pub register_start: Timestamp,
}

When we query per agent, the ExpressJS route will likely look like this, but feel free to deviate if you think it's best:

app.get('/agent/:agentAddress', (req, res) => {
  // …
})

This will return all the data about the agent, but most importantly the balance. We'll also want to return the agent's protocol balances, which means how many native tokens they have. (Let's not worry about cw20s right now in this ticket)