-
Notifications
You must be signed in to change notification settings - Fork 11.7k
Add transaction handler RPC for Mysticeti fastpath #19401
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
Conversation
This will not function until consensus adapter/handler side is implemented.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
&self, | ||
request: tonic::Request<HandleTransactionRequestV2>, | ||
// TODO: Do we want to make a new response type for this? | ||
) -> WrappedServiceResponse<HandleCertificateResponseV3> { |
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.
It seems more refactoring will be needed to support soft bundle. Most of the logic here should be shared between handle_transaction_v2 and handle_soft_bundle_transactions_v2 handlers. Or we can take the opportunity to support batched transaction submission with a single handler, which should cover the soft bundle use case as well.
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.
Yes, I was not originally planning to support soft bundle for the first prototype. do you think that's worth adding to this PR?
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.
As discussed, we can definitely can back and refactor later.
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.
How does this look like with #19320?
} | ||
|
||
#[instrument(level = "trace", skip_all)] | ||
pub async fn handle_transaction_v2( |
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 doesn't seem to be the right naming anymore since we are only doing various checks here.
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.
Do you have an alternate suggestion for name?
I think actually the existing handle_transaction
was poorly named and should have been called sign_transaction
. But for the new one I'm adding, handle
is more apt because we really are handling the full transaction e2e: sending an unsigned tx through consensus, executing it, and returning the effects. I didn't think temporary confusion of naming overload would be too bad, bc eventually we plan to remove the old version.
I don't think anything changes here? We aren't acquiring locks for the tx in the RPC handler anymore, that will need to be done on the consensus handler side |
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 but let's wait for a day or two for reviews from other folks.
This will not function until consensus adapter/handler side is implemented.