Database Confirmed field correct meaning

Moralis General
#1

Hello, I’ve read in the forum that the confirmed firld in the database collections is related to the concurrency of blocks writing in the blockchain.

My questions is, once an event that is related to a blockchain transaction is executed (and synced in the Moralis database with a new record), is it possible that the transaction can be reverted (failed / not confirmed) and the event sync record is not “correct”, or not?

Can I trust the new record writing in the database, to execute other functions related to the transaction, or I need to wait for the “confirmed” field switched to true?

Thanks

#2

Have a read here: Time for Automatic Synchronization of Contract and Address Transactions

is it possible that the transaction can be reverted (failed / not confirmed) and the event sync record is not “correct”, or not?

It could happen in rare situations so you may want to implement other checks.

1 Like
#3

Thank you, there is an answer from you in that discussion:

suppose in that case you could check for an event on the contract you’re interacting with as a backup that the transaction was finalized.

I have an event indeed that writes in the Moralis database.

Just to be sure I understood the flow, it can happen that:

There is a transaction
An event is triggered and a new row is written in the Moralis collection (event sync)
The transaction fails
The row is in the collection but represents a failed transaction (confirmed false?)

As far as I know if a transaction fails the entire block, including the event, is reverted and not confirmed. Is this represented by the previous flow?

Thanks

#4

it can be various cases, there can be a block reorg and the transaction/event can still be confirmed, but in a different block number or in the same block number, or the transaction can fail after reorg (rarely it happens this)

after a number of blocks confirmed that transactions that included the event, we also set that confirmed flag for that particular event

#5

Ok, about this:

or the transaction can fail after reorg (rarely it happens this)

we would have confirmed at false in that case, or is it possible to have it at true despite the failed transaction?

Thanks

#6

it should be with confirmed false in this case

you will also notice duplicate events in case of reorgs, with one event as confirmed and one as unconfirmed