Starknet-rs Deployment: Checking Transaction Status for Subsequent Invocation

[omarespejel]

Hey! Big fan of starknet-rs here.

We're currently authoring tutorials about starknet-rs for the StarkNet Book. As part of this effort, we're developing a function that deploys a contract and then calls upon this newly deployed contract, all within the same script.

To ensure seamless operation, we need to verify that the contract deployment transaction has been accepted on L2 before we proceed to the invocation part. Could you recommend the best approach for confirming a transaction's status on L2 using starknet-rs?

I can imagine something like:

SequencerGatewayProvider::starknet_alpha_goerli()
            .wait_for_tx(BlockId::Pending, &transaction_hash, None)
            .unwrap();

Specifically, we're looking for a function or method that efficiently fetches the status of a specific transaction hash, and then allows further execution only if the status is 'Accepted' on L2.

Thank you for your time and support.

Best Regards,

[xJonathanLEI]

Thanks for reaching out and I'm glad you like the library :)

Transaction watching isn't something that's built-in right now, and applications must implement their own watching logic. For example, this is how it's currently implemented in starkli:

https://github.com/xJonathanLEI/starkli/blob/caaa498df772ac68a1ea3965d74d5ca02dcaa0d1/src/utils.rs#L11_L40

This feature should be part of starknet-rs though. I'd imagine a dedicated TransactionWatcher type that can be either manually constructed or converted from any transaction submission response tyoes. And with this type users should be able to configure poll interval, timeout, and expected transaction status.

That said, as of today, a naive loop as demostrated in the starkli example above should be the best way.

I'll leave this issue open for tracking the implementation of this feature.

[omarespejel]

Thanks for the speedy response, @xJonathanLEI! Thank you for referencing me to the watch_tx function, I will be employing a similar logic in the Book tutorial! Our goal is to get more persons to use starknet-rs.

Also, your insights make sense - a built-in TransactionWatcher could be a strong addition to starknet-rs. For now, using the simple loop from starkli seems like our best bet for the Book. Looking forward to tracking the progress of this feature.

Thanks for keeping the conversation open!

[tdelabro]

Could be cool to have it in the lib tho. It's really often that you will wait for your tx to be accepted before proceeding with something else

[xJonathanLEI]

Yeah this would be useful. Will prioritize this.

[tdelabro]

Tell me if I'm wrong, but I believe you cannot use a newly declared contract in the same block it was declared. You have to wait for b+1, before being able to deploy it. I don't know if it is a chain behavior or a lib behavior (or maybe it is just a nonce issue), but the bottom line is that, for DeclareTx, we should wait not only for the TX to be accepted but also for the block to be closed.

[xJonathanLEI]

I'm pretty sure you can indeed use the newly declared class in the same block as I believe I've done exactly that multiple times.

[tdelabro]

I don't know what was the issue I faced then, but the solution was to wait for the next block before sending the second tx. Is is just the nonce issue? The same account sending two tx resulting in nonce conflict?

[xJonathanLEI]

Likely a nonce issue. Maybe your account isn't setting to use pending. Or maybe the node you're querying against hasn't accounted for the pending state update.

In fact, even if you internally manage nonce and locally increment it, you still have to wait for the node you're submitting against to account for the pending update to be able to successfully validate the request, as I believe the node impls we have right now do not accept future nonces.