Skip to content
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

Fix batch tx send encoding #11500

Merged
merged 13 commits into from
Dec 15, 2023
Merged

Conversation

amit-momin
Copy link
Contributor

  • Changed the batch tx send encoding to use MarshalBinary. The encoding was causing an invalid RLP error when resending tx's in batch. The client was unable to properly decode the tx which was using UnmarshalBinary under the hood.
  • Removed the use of types.NewTransaction which has been deprecated. It was replaced with types.NewTx called on a types.LegacyTx object.

Copy link
Contributor

github-actions bot commented Dec 5, 2023

I see that you haven't updated any README files. Would it make sense to do so?

@amit-momin amit-momin marked this pull request as ready for review December 6, 2023 23:09
@@ -424,6 +424,7 @@ func ClassifySendError(err error, lggr logger.Logger, tx *types.Transaction, fro
return commonclient.Fatal, err
}
if sendError.IsNonceTooLowError() || sendError.IsTransactionAlreadyMined() {
lggr.Debugw("Transaction already confirmed for this nonce: %d", tx.Nonce(), "err", sendError)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some of these messages we already log on the caller side, so you might want to aggregate those.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be alright to keep both? The caller would be able to provide more info potentially and it'd also make tracing the call easier. And keeping it the logs in the ClassifySendError ensures we get a log for all of these even if the caller side doesn't

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not against it, but if we keep them let's try to differentiate the 2 messages to get more context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the error logging in the broadcaster and confirmer to avoid re-logging the same thing as the ClassifySendError function

@@ -413,20 +413,21 @@ func ExtractRPCError(baseErr error) (*JsonError, error) {
return &jErr, nil
}

func ClassifySendError(err error, lggr logger.Logger, tx *types.Transaction, fromAddress common.Address, isL2 bool) (commonclient.SendTxReturnCode, error) {
func ClassifySendError(err error, lggr logger.Logger, tx *types.Transaction, fromAddress common.Address, isL2 bool) commonclient.SendTxReturnCode {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice cleanup here :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

out of curiosity is there any reason we dont grab the fromAddress from the tx?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I think it's because this Transaction type isn't our internal one but the go-ethereum one which doesn't expose the from address.

return
}
codes[i], txErrs[i] = client.ClassifySendError(reqs[i].Error, lggr, tx, attempts[i].Tx.FromAddress, c.client.IsL2())
sendErr := reqs[i].Error
codes[i] = client.ClassifySendError(sendErr, lggr, tx, attempts[i].Tx.FromAddress, c.client.IsL2())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what scenarios can the attempt.FromAddress differ from the tx.FromAddress?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're just resorting to getting the from address from the attempt here because you can't get it through the go-ethereum Transaction tx

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry didnt see you previous message :)

Copy link
Contributor

@prashantkumar1982 prashantkumar1982 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you also need to make the change to this logic for batch Txs:

Args: []interface{}{hexutil.Encode(attempt.SignedRawTx)},

The other places that you've changed, don't seem to be used for batched sending, just regular sending of unbatched Txs.

Copy link
Contributor

@prashantkumar1982 prashantkumar1982 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, just 1 nit on adding a comment to explain the batching code!

if decodeErr != nil {
return reqs, now, successfulBroadcast, fmt.Errorf("failed to decode signed raw tx into Transaction object: %w", decodeErr)
}
txBytes, marshalErr := signedTx.MarshalBinary()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain via a comment, why do we have to decode the raw tx and encode it again before sending in batched req?

@cl-sonarqube-production
Copy link

@prashantkumar1982 prashantkumar1982 added this pull request to the merge queue Dec 15, 2023
Merged via the queue into develop with commit 0b99f3a Dec 15, 2023
83 of 84 checks passed
@prashantkumar1982 prashantkumar1982 deleted the bug/fix-batch-tx-encoding branch December 15, 2023 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants