-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature]: add --wait
flag for all tx
subcommands
#19821
Comments
The problem is, CometBFT's RPC will most likely timeout and you need to handle that error (this is why we removed block to begin with). However, a --wait flag could silently ignore that error and still try and query for you. WDYT @julienrbrt? |
Exactly, that's what I meant with "polling the node". I also implemented similar behaviors in a couple of automated scripts that needed to send multiple transactions, but I needed them to wait for the previous transaction to complete. |
This related to this: #18927 (comment) |
Given that this question pops up often, maybe we should document this command😅 |
Hey Julien, thanks, I didn't know about that command! IMHO the name and the description are not helping, the description should at least say: "Wait for a transaction to be included in a block" instead of "Query for a transaction by hash". Additionally, I'd also like to be able to pipe two commands:
Just to avoid having to copy-paste the hash. If the transaction was already included, that command just hangs in there and finally exits with error:
I think we can make it more resilient to not rely on websocket only, but also to normal query for the tx hash. For now what I was able to do is this:
|
I implemented my version of the command here: warden-protocol/wardenprotocol#115. If you would like this to be integrated in SDK directly, just let me know and I'll open a patch! Thanks for pointing me in the right direction with |
Feel free to upstream improvements yes 🙏 |
Summary
Back when we had the
BROADCAST_MODE_BLOCK
, it was possible to send a tx from the cli and wait for it to be included in a block, showing its results.Problem Definition
I find myself, especially during development, but not only, to send a tx like:
Just to then run:
To check whether it went through correctly or not.
Proposed Feature
My proposal would be to introduce a
--wait
flag:That essentially behaves like
BROADCAST_MODE_BLOCK
did, but waits on the client side (e.g. by polling the node).Maybe we should take it even further and also have the possibility of specifying a timeout:
The text was updated successfully, but these errors were encountered: