Closed dfstio closed 3 weeks ago
Thanks for creating the issue! I'll try to reproduce this week and see if a fix can follow ASAP.
It is a minascan log from https://api.minascan.io/archive/berkeley/v1/graphql archive node:
actions(
input: {address: "B62qjirMYUSyjb1AcyNmAF5dLqTk3KQuoUYKv5FGdx618GDmRfYNAME", fromActionState: "15883099431178491989573353483798785787585407519424468142944726203792446252042", endActionState: "5766519161874551854426173362531259652853737507928229135738402350087629707642"}
)
response:
{
"data": {
"actions": []
}
}
It seems that o1js sends the correct query, and the problem is on the archive node side.
I also see many "Failed to derive correct actions hash" errors when sending and fetching 64 actions.
It seems like the expected hash is incorrect, and it is related to the https://github.com/o1-labs/Archive-Node-API/issues/7 This error goes away after 40 min for 64 actions and after 2 hours for 128 actions.
I did some testing on my end using the zkApp Lightnet, posting some results here for others to read.
The SQL for getting actions with endActionState
defined seems to be working okay, I don't think it's an issue with the SQL itself. Dispatching actions and specifying fromActionState
and endActionState
works on my end. The Archive Node API will return an empty list if either is not present in the Postgres DB when executing the query.
This means the issue can possibly be as you pointed out, it can be due to a bug with how https://github.com/o1-labs/Archive-Node-API/issues/7 was implemented. The issue is probably something as follows:
The Archive Node API uses the Archive Node Postgres database to get all action data recorded from a Mina daemon connected to the network. As blocks are produced and gossiped at the best tip of the network, the Postgres DB will have multiple blocks showing as the best tip. The Mina daemon has consensus logic to determine the best chain, and the Archive Node tries to use the same reasoning to decide what the best tip block is.
What might be happening is that the best tip block between the Archive Node API and the Mina daemon do not agree, which leads to incorrect results. This means fixing the consensus logic in the Archive Node API.
I have a WIP PR here: https://github.com/o1-labs/Archive-Node-API/pull/102
On Berkeley testnet, calling
returns an empty list when endActionState is not undefined. It works as expected when endActionState is undefined.
This behavior is the same on minascan and minaexplorer endpoints.
The test code: https://github.com/dfstio/merkle-map-demo/blob/endActionState/tests/actions.test.ts
The test code log: