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: fixing forced batches error handling and normal batches transaction level error handling. #2100

Merged
merged 6 commits into from
May 16, 2023

Conversation

Psykepro
Copy link
Contributor

@Psykepro Psykepro commented May 15, 2023

Closes #2099.

What does this PR do?

Fixing:

  • The full error handling for Forced Batches.
  • The transaction level error handling for Normal Batches.
  • The case for parsingErrIntrinsicInvalidBatchGasLimit in RomErrorCode function of the state

Reviewers

Main reviewers:

Codeowner reviewers:

@Psykepro Psykepro requested a review from tclemos as a code owner May 15, 2023 13:57
@Psykepro Psykepro self-assigned this May 15, 2023
@cla-bot cla-bot bot added the cla-signed label May 15, 2023
@Psykepro Psykepro force-pushed the feature/fix-forced-batches-err-handling branch 2 times, most recently from 9265c2b to f69f520 Compare May 15, 2023 14:02
Copy link
Contributor

@ARR552 ARR552 left a comment

Choose a reason for hiding this comment

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

What about the list of errors that increase the nonce??

@@ -399,7 +398,8 @@ func (f *finalizer) processTransaction(ctx context.Context, tx *TxTracker) error
// handleTxProcessResp handles the response of transaction processing.
func (f *finalizer) handleTxProcessResp(ctx context.Context, tx *TxTracker, result *state.ProcessBatchResponse, oldStateRoot common.Hash) error {
// Handle Transaction Error
if result.Responses[0].RomError != nil && !errors.Is(result.Responses[0].RomError, runtime.ErrExecutionReverted) {
if !result.IsBatchProcessed {
// If intrinsic error or OOC error, we skip adding the transaction to the batch
f.handleTransactionError(ctx, result, tx)
return result.Responses[0].RomError
Copy link
Contributor

Choose a reason for hiding this comment

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

Why returning thefirst response?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here we process 1 by 1 we always can have only 1 response

if err != nil {
return lastBatchNumberInState, stateRoot
}
_ = f.handleForcedTxsProcessResp(request, response, stateRoot)
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we ignore the error?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

because nothing happens even if we have error I can just remove returning it

Comment on lines 426 to 428
romErr := executor.RomErrorCode(txResp.RomError)
if txResp.RomError != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
romErr := executor.RomErrorCode(txResp.RomError)
if txResp.RomError != nil {
if txResp.RomError != nil {
romErr := executor.RomErrorCode(txResp.RomError)

return txResp.RomError
} else if executor.IsIntrinsicError(romErr) {
// If we have an intrinsic error, we should continue processing the batch, but skip the transaction
if txResp.RomError != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is redundant

log.Warnf("handleForcedBatchProcessResp: ROM out of counters error: %s", txResp.RomError)
romErr := executor.RomErrorCode(txResp.RomError)
if txResp.RomError != nil {
if executor.IsROMOutOfCountersError(romErr) {

Choose a reason for hiding this comment

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

if the batch has an out of counters, no transaction should be added.
I thinks that here, if there is the error in the 4th transaction for example, the first 3 ones will be stored and they should not

Copy link
Contributor Author

@Psykepro Psykepro May 15, 2023

Choose a reason for hiding this comment

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

@ARR552

What about the list of errors that increase the nonce??

Those will be added. We don't skip them.

@Psykepro Psykepro force-pushed the feature/fix-forced-batches-err-handling branch from f69f520 to f02c4b2 Compare May 15, 2023 14:36
@Psykepro Psykepro requested review from krlosMata and ARR552 May 15, 2023 14:36
Copy link

@krlosMata krlosMata left a comment

Choose a reason for hiding this comment

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

😸

…ion level error handling.

Signed-off-by: Nikolay Nedkov <nikolai_nedkov@yahoo.com>
@Psykepro Psykepro force-pushed the feature/fix-forced-batches-err-handling branch from f02c4b2 to 96a6a5a Compare May 15, 2023 16:35
ToniRamirezM and others added 5 commits May 16, 2023 13:38
Signed-off-by: Nikolay Nedkov <nikolai_nedkov@yahoo.com>
Signed-off-by: Nikolay Nedkov <nikolai_nedkov@yahoo.com>
@Psykepro Psykepro merged commit ce27fdd into develop May 16, 2023
@Psykepro Psykepro deleted the feature/fix-forced-batches-err-handling branch May 16, 2023 13:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix error handling in OOC for forced batches
4 participants