Proposal for waitForTransaction improvement

[Cussone]

Now that block times are much faster it would make sense to lower the retryInterval param from 5000ms (waited on twice, so it's 10s) to something more realistic.

Also, I find it weird that retryInterval is an optional param. In my opinion, it would make more sense to require it explicitly, with a suggested value in the docs. I see it as a better DX.

This would be a breaking change. So, it is something to consider for the next major release.

[martinvibes]

hello @Cussone can i hop on this issue?

[Cussone]

hello @Cussone can i hop on this issue?

Not sure what you are referring to, but feel free to write anything you think about this.

[PhilippeR26]

Has been discussed in Slack: will not be modified, as user can customize the value.

[Cussone]

Has been discussed in Slack: will not be modified, as user can customize the value.

Yup, that was the conclusion for the current version, but I opened this proposal for the next version, as we also discussed on Slack.

[Sekhmet]

Another improvements would be:

• do not call sleep after receipt is successfully resolved here - right now even if transaction is ready we are still waiting for 5s.
• do not call sleep on entry here

I've had issue with my tests where everything was super slow (even when using starknet-devnet) and actually the issue is that each call to waitForTransaction will take at least 10s unless you modify transactionRetryIntervalFallback.