How much time/how many confirmations does the blockfrost provider need to sync up?

[peter-mlabs]

I have a vague-ish question that I could use some help tracking down the answer to.

I have run in to a few situations where I've done something akin to

foo = do 
  tx1 <- run contract1
  submitAndAwait tx1

 res <- fetchResultFromTx1

  tx2 <- run $  contract2 res
  submitAndAwait tx2 
  (...)

where:

• run is the proper invocation of runGYTxMonadNode or similar,
• submitAndAwait is gySubmitTx followed by gyAwaitTxConfirmed, and
• fetchResultFromTx1 is some runGYTxQueryMonadNode call
• tx2 somehow depends inputs of tx1.

After some debugging, I've found that although blockfrost seems to report the result of tx1 as "confirmed", but the subsequent query appears to not actually find it properly updated. (I put "appears" in italics, because it's possible that this is not actually the case, and I have a bug elsewhere.)

Bumping the confirmations that gyAwaitTxConfirmed looks for from 1 to 2 seemed to help the situation somewhat, but not entirely. I'm going to try a higher number of confirmations, but I'm wondering what best practice is here.

Can anyone with more knowledge of blockfrost/atlas chime in here? My mental model of both assumed that once the confirmation goes through, both blockfrost/atlas should be fully in sync, but I've had this assumption violated on other frameworks before.

[sourabhxyz]

"dep" is a typo in "tx2 somehow dep spends inputs of tx1."?

From "subsequent query" in

After some debugging, I've found that although blockfrost seems to report the result of tx1 as "confirmed", but the subsequent query appears to not actually find it properly updated.

you mean that in step "submitAndAwait tx2", transaction builder is selecting inputs which have already been spent by tx1? If that is so, coin selection process would select additional UTxOs from wallet by first querying all UTxOs at wallet address using the configured provider, which in our case shouldn't return for already spent UTxOs so perhaps issue is not there but what could have happened is in your transaction skeleton itself you may have specified an input which is also present as input in skeleton of tx1. Could you see if that is not the case?

Regarding number of confirmations, 1 should be fine unless there is a bug in our code/assumptions.

[peter-mlabs]

Thanks for the response! I'll keep an eye on this -- it's helpful information. I seem to have refactor to a point where things seem more stable now, so 1 confirmation may be all it needs (barring rollbacks, of course.)