o1js
o1js copied to clipboard
Failing transaction flow with `endActionsHash`
This PR modifies the transaction flow actions & reducer tests, so that they actually check that the transaction outcome is correct. It works on local blockchain but consistently fails with lightnet, and the added debug logs reveal that getActions
always returns an empty list of actions when endActionState
is used.
On main
, we disabled the endActionState
argument to be able to merge a PR which exposed (but not introduced) this problem: https://github.com/o1-labs/o1js/pull/1577/commits/af580c0a05e5ff5acc27b08e5a953aa41ead8eff
Notes:
- I don't know yet if
endActionState
is the actual problem or if the test would succeed without it, because no previous version of the test other than in this PR would have failed on an action list that's always empty - Also not sure if this is specific to the archive node - Mina interaction on lightnet. For example, with what latency can we expect actions to arrive in the archive node API after the node published them? Are the two even properly connected?
In summary failed job has logs attached: https://github.com/o1-labs/o1js/actions/runs/8743722468?pr=1597 These logs are from the Lightnet processes (mina daemon, archive node, archive-node-api). This will let you debug further. I can help you with that if you'd like to. Also might be helpful to run this tests of this branch on local instance of the lightnet and follow the docker container processes logs to see in real time what is going on.
The same problem exists on the Berkeley testnet: https://github.com/o1-labs/o1js/issues/1426
- Also not sure if this is specific to the archive node - Mina interaction on lightnet. For example, with what latency can we expect actions to arrive in the archive node API after the node published them? Are the two even properly connected?
On Berkeley, I've seen latency of up to 2 hours. It means that I should wait two hours to start reducing the actions after the actions have been sent: https://github.com/o1-labs/o1js/issues/1426#issuecomment-1938787799