Wait helper: pending operation can be already included

[m-kus]

Resolves #297

Based on

2022-04-26 01:58:16.147Z INFO shell Found new block BMMcivYhsijhCNq7PqqTVKyFAKWgCgow1WBF8K2NbUs8Xxv35aC (0 sec delay)
2022-04-26 01:58:17.102Z INFO shell Operation oopwxbhhcCfCm27Gg5aJ16jCG93f9BYLY71untJoEbktZQ55MpA is still in mempool
2022-04-26 01:58:17.622Z INFO shell Sleep 28 seconds until block BMMcivYhsijhCNq7PqqTVKyFAKWgCgow1WBF8K2NbUs8Xxv35aC is superseded

and given that operation was included in that block https://tzkt.io/oopwxbhhcCfCm27Gg5aJ16jCG93f9BYLY71untJoEbktZQ55MpA I think this is the case.

[steampoweredtaco]

FYI. I tried out this change with a ttl=60 for a batch operation of 41 simple xtz transations but the TTL of 60 timed out. The time out from start of simulation to failure was 10 minutes so that should of been only about 20 blocks right? It seems unrealistic that it should take that long to simulate though, but either way the ttl didn't seem to be honored. I'm not sure if the issue would be related to this change, but I thought I'd give ya a heads up before the PR is completed.

The line before the WARNING log line is timestamped for right before the send call and the WARNING line timestamp is the time the branched block, too old error occurs.

[m-kus]

Thanks for the heads up! Yeah, I think it's not directly related, but I'll try to fix it in this PR. Do I understand correctly that you have tried to send a batch and it was actually included in chain, but pytezos didn't detect that?

[steampoweredtaco]

Thanks for the heads up! Yeah, I think it's not directly related, but I'll try to fix it in this PR. Do I understand correctly that you have tried to send a batch and it was actually included in chain, but pytezos didn't detect that?

For the original issue this PR is attached to that is correct, the batch operation made it on chain but was never confirmed by pytezos.

When I tried to use this change it never made it on-chain because of the TTL expiring even set to 60 with a batch operation of 41 xtz transfers, no contract calls. I think the TTL expired during the simulation.

[m-kus]

@steampoweredtaco I have additionally made some optimizations that should decrease the building time of a batch. Separately, there can be an early return from the confirmation loop due to reorgs, but I will address that issue in another PR.

[steampoweredtaco]

@steampoweredtaco I have additionally made some optimizations that should decrease the building time of a batch. Separately, there can be an early return from the confirmation loop due to reorgs, but I will address that issue in another PR.

Could you clarify for me what I should do if I get a reorg error before it is addressed? Does this mean the operation won't be submitted or that I need to retry confirming? If I want to retry confirming the operation because it still can pass, is the new hash on the error sufficient? How would I use it to reattempt the confirmation manually?

[m-kus]

With safe TTL < 120 you don't need to re-submit the operation, just retry to confirm. There is pytezos.wait helper you can use for that, something like:

try:
  opg = pytezos.transaction(...).send()
except ReorgError:
  pytezos.wait(opg)