fix: retry on TransactionHashNotFound error

[lambda-0x]

related: #1340

we are only calling get_transaction_receipt after we get Accepted_on_L2/Accepted_on_L1 from get_transaction_status, still rpc returns TransactionHashNotFound in which case we simply retry after sometime.

[codecov-commenter]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (942d895) 67.55% compared to head (a3535d6) 67.62%.
Report is 3 commits behind head on main.

Files	Patch %	Lines
crates/dojo-world/src/utils.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1435      +/-   ##
==========================================
+ Coverage   67.55%   67.62%   +0.06%     
==========================================
  Files         218      218              
  Lines       21011    21055      +44     
==========================================
+ Hits        14195    14238      +43     
- Misses       6816     6817       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kariy]

I was under the assumption that the receipt should be available if the status is already ACCEPTED_ON_* (which is the current behaviour of katana). Does that mean the tx status doesn't exactly enforce the availability of the receipt?

But, anyway, I think this change is good.

[tarrencev]

I think the issue is when you're using a rpc provider like alchemy, where they are running multiple pathfinder instances, and your requests are load balanced. basically the execute will happen on a different rpc node from the get txn and there can be a delay between the first node executing and the second node receiving the txn

[kariy]

I think the issue is when you're using a rpc provider like alchemy, where they are running multiple pathfinder instances, and your requests are load balanced. basically the execute will happen on a different rpc node from the get txn and there can be a delay between the first node executing and the second node receiving the txn

ah make sense

[lambda-0x]

I think the issue is when you're using a rpc provider like alchemy, where they are running multiple pathfinder instances, and your requests are load balanced. basically the execute will happen on a different rpc node from the get txn and there can be a delay between the first node executing and the second node receiving the txn

oh i thought it was a bug in RPC, but this explanation makes more sense