Is live query faster than .wait(1)

Moralis General
#1

I have a system in place to submit transaction using
const transaction = await Moralis.executeFunction(sendOptions);
const receipt = await transaction.wait(1);

This smartContract function emits an Event that I monitor using a LiveQuery which updates my App. I am finding on Polygon Mumbai that the live Query picks up an event 5-10 seconds BEFORE the wait function has finished. ie. the receipt is very often generated several seconds AFTER the live query has picked up an event generated by the contract.

Do you have an explanation for this? Does this mean that events picks up yet unapproved transactions?

Or alternatively, is .wait(1) somehow slow ?

This is important because, on my DAPP, the website actually updates quite quickly thanks to the event but I am not giving back control because apparently .wait is not finished, which is weird from a user perspective.

Thanks!

#2

you could check on chain (in a block explorer) the timestamp when the live query triggered and the block timestamp, you can also see the blocktimestamp in db for that event and see what it is the delay

#3

Just checked, so
So a transaction was included in the blockchain at
2022-02-18T08:38:49.000Z

The associated event on the Moralis database was created
2022-02-18T08:38:49.879Z

So 0.879 s later which is good ( :slight_smile: ) and expected . BUT STILL, on my APP, the event was displayed BEFORE wait(1) gave back control.

#4

Could there be something inside of wait(1) that is slower than needed? is there a loop with a given delta that is too slow for polygon?

#5

maybe the app gets that data from metamask, that uses a RPC node, and maybe it waits few blocks until it is considered as confirmed

#6

Ah good call. It is possible. How do I by pass this if it is the case?

#7

but the wait functions takes an input for number of confirmation blocks. How does that is expected to work otherwise?

#8

@cryptokid from looking at the code, it looks like this function is a pure one to one wrapper to transaction.wait of ethers.js

transaction.wait( [ confirms = 1 ] ) ⇒ Promise< [TransactionReceipt](https://docs.ethers.io/v5/api/providers/types/#providers-TransactionReceipt) >

Resolves to the [TransactionReceipt](https://docs.ethers.io/v5/api/providers/types/#providers-TransactionReceipt) once the transaction has been included in the chain for *confirms* blocks. If *confirms* is 0, and the transaction has not been mined, `null` is returned.

If the transaction execution failed (i.e. the receipt status is `0`), a [CALL_EXCEPTION](https://docs.ethers.io/v5/api/utils/logger/#errors--call-exception) error will be rejected with the following properties:

* `error.transaction` - the original transaction
* `error.transactionHash` - the hash of the transaction
* `error.receipt` - the actual receipt, with the status of `0`

If the transaction is replaced by another transaction, a [TRANSACTION_REPLACED](https://docs.ethers.io/v5/api/utils/logger/#errors--transaction-replaced) error will be rejected with the following properties:

* `error.hash` - the hash of the original transaction which was replaced
* `error.reason` - a string reason; one of `"repriced"`, `"cancelled"`or `"replaced"`
* `error.cancelled` - a boolean; a `"repriced"` transaction is not considered cancelled, but `"cancelled"` and `"replaced"` are
* `error.replacement` - the replacement transaction (a [TransactionResponse](https://docs.ethers.io/v5/api/providers/types/#providers-TransactionResponse))
* `error.receipt` - the receipt of the replacement transaction (a [TransactionReceipt](https://docs.ethers.io/v5/api/providers/types/#providers-TransactionReceipt))

.wait(1) will wait for the inclusion in one block. So it does not make sense that it would be slower than detecting the events. I am still questioning whether Moralis Wrapper is adding this delay.

#9

Confirms 1 may mean one confirmation that should mean 2 blocks

#10

I tested wait(0) and it juste return an empty receipt. From the doc, 1 block confirmation just means inclusion in the chain I think.

#11

Is there more insights on this? Having to wait 15 seconds instead of 5 is a huge UI experience change for. I am considering not using this .wait function as a result. I don’t think this is the intent of the development of this API.

#12

I don’t think that it is the api problem, as fast the response should be received from the RPC node it should return

#13

Is moralis doing some event pre block caching before functions are included in the chain ?

#14

Alternatively this could be the speedy nodes of moralis being out of sync with the nodes of MetaMask ?

#15

you could try with another node in metamask, you could also look in the source code for Moralis SDK