bug: database error on sync

0xPolygonMiden / miden-client

Client library that facilitates interaction with the Miden rollup

MIT License

32 stars 28 forks source link

bug: database error on sync #360

Closed mFragaBA closed 1 week ago

mFragaBA commented 4 months ago

If we submit two transactions using the same account (that end up in different blocks), we get this weird interaction where we do a sync and get the following error:

~/l/miden-client tomyrd-refactor-note-list ?1 ❯ miden sync                      
store error: database-related non-query error: UNIQUE constraint failed: accounts.id, accounts.nonce

However, after a second sync the error does not appear anymore:

~/l/miden-client tomyrd-refactor-note-list ?1 ❯ miden sync           
State synced to block 622
New public notes: 0
Tracked notes updated: 2
Tracked notes consumed: 0
Tracked accounts updated: 0
Commited transactions: 1

Because of the errors, some transactions do not get marked as committed.

Some extra details:

the faucet account I used is an onchain account
I have only been able to reproduce it if I start with a new faucet. After the first 2 txs I haven't been able to

igamigo commented 4 months ago

After reviewing this, it seems the error just seems to be that the second transaction does not get finalized into a block for some seconds and that's why the first sync can fail but the second does not. However, a couple of things of note:

This will happen for both onchain and offchain accounts. The error is a bit different for offchain accounts (store error: account hash mismatch for account 0xa561d49b189993d3). Onchain accounts should probably not error.
In the case where 2 transactions are executed without a sync in between, the first transaction is not getting marked as committed, probably due to the fact that we are taking hash updates as a necessary condition for committing transactions. Account hash updates are only sent if they are the last update. Based on this we probably want to change the conditions we check to mark transactions as committed to be || instead of &&.

This is probably what was reported on #314

mFragaBA commented 2 months ago

we found one more issue similar to this one. Again for partial notes, and it happens when you export a partial note and the receiving client syncs past the block where the note gets included. In this case the issue happens only for non-ignored notes as the ignored notes get the inclusion info without using the sync state

igamigo commented 1 week ago

This is done since #412 (later changed to implement new RPC types which contain new information related to committed transactions)