-
Notifications
You must be signed in to change notification settings - Fork 261
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
Implement new API for sign_and_submit_then_watch
#354
Conversation
So, I'm fairly happy with this API now overall. Some things that come out of this PR that could be addressed separately:
|
src/client.rs
Outdated
}) | ||
// If we successfully obtain the block hash we think contains our | ||
// extrinsic, the extrinsic should be in there somewhere.. | ||
.ok_or(Error::Transaction(TransactionError::BlockHashNotFound))?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this error message could be a little confusing:
Block hash containing non-finalized transaction can no longer be found
maybe 'extrinsic not found' or 'extrinsic position not found' instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up going for "The block containing the transaction can no longer be found (perhaps it was on a non-finalized fork?)"; what do you reckon?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty clean to me, nj
@gregdhill @sander2 you guys may both be interested in this PR, and it would def break some stuff :) See the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! A few nitpicks.
src/client.rs
Outdated
pub enum TransactionProgressStatus<'client, T: Config> { | ||
/// Transaction is part of the future queue. | ||
pub enum TransactionStatus<'client, T: Config> { | ||
/// The transaction is part of the "future" queue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// The transaction is part of the "future" queue. | |
/// The transaction is part of the "future" queue in the transaction pool. |
maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure enough on the terminology to really know! are "future" and "ready" transactions both part of the pool?
The substrate glossary for transaction pool: "A collection of transactions that are not yet included in blocks but have been determined to be valid."
Maybe Future transactions haven't been validated yet? But in the big comment, they do mention "future and ready pool"...
Anyway, shrug, I'd lean towards playing it safe and leaving it as is for now :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe @ascjones knows? Either way, fine by me to leave it as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This distinction is new to me TBH
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
src/client.rs
Outdated
pub enum TransactionProgressStatus<'client, T: Config> { | ||
/// Transaction is part of the future queue. | ||
pub enum TransactionStatus<'client, T: Config> { | ||
/// The transaction is part of the "future" queue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This distinction is new to me TBH
src/client.rs
Outdated
/// - `Retracted` | ||
/// 5. Block finalized: | ||
/// - `Finalized` | ||
/// - `FinalityTimeout` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice categorisation. Would it bring any value to bring this grouping to the type level, instead of the simple 1 => 1 mapping with TransactionStatus
? i.e. split the groups into their own enums combined as variants in the top level enum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reckon there are few enough "groups", and things can move between them easily enough, that the flat enum is probably easier to work with (since one mode of use involves matching on variants), and has the nice benefit of aligning very closely with thr substrate version, and so easy to keep in sync going forwards :)
src/client.rs
Outdated
@@ -280,3 +284,416 @@ where | |||
Ok(signed) | |||
} | |||
} | |||
|
|||
/// This struct represents a subscription to the progress of some transaction, and is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reckon all this stuff deserves it's own file, shouldn't be in client.rs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually did do this initially. I like the separation; I just wasn't keen on the circular dependency it would introduce (client makes a transactionprogress, transactionprogress et al have a reference to client) :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I think I'll give it a try anyway though, because it would be nice breaking that file down!)
* WIP Implementing new event subscription API * back to lifetimes, fix example * no more need for accept_weak_inclusion * thread lifetime through to prevent 'temporary dropped' issue * make working with events a little nicer * Get tests compiling * fmt and clippy * _name back to name * dont take ownership, just have stronger note * Attempt to fix test * remove commented-out code * Add a couple more helper methods and a test * Remove custom ExtrinsicFailed handling; treat them like other events * Handle runtime errors in TransactionProgress related bits * cargo fmt + clippy * Fix some of the failing tests * remove unused import * fix transfer_error test * Fix compile errors against new substrate latest * Comment tweaks, and force test-runtime rebuild * Drop the TransactionProgress subscription when we hit 'end' statuses * cargo fmt * find_event to find_first_event and helper to return all matching events * TransactionProgressStatus to TransactionStatus * Copy and improve docs on TransactionStatus from substrate * debug impl for Client to avoid manual debug impls elsewhere * Add and tweak comments, specifically a note about block inclusion on errors * clippy + fmt * Fix docs * Ignore 'error' statuses and adhere to the substrate docs * tweak and improve some comments per @dvdplm's suggestions * Break transaction* structs into separate file * fmt and fix doc link
This PR is an attempt to implement the API for subscribing to transaction state and obtaining events as described in #312.
Closes #312