miner: reset ctx timeout before commit tx on new tx notif

[manav2401]

Description

A recent refactor in miner module caused an internal sentry node to continuously print the following logs:

Tx Level Interrupt                       hash=000000..000000

On further investigation, this channel in main loop always used to trigger a call to commit transactions.

bor/miner/worker.go

Line 606 in d1219ff

case ev := <-w.txsCh:

Because we use a shared context throughout the worker, it used to set an already timed out context which used to trigger this.

bor/miner/worker.go

Line 940 in d1219ff

case <-w.interruptCtx.Done():

Moreover, this case is to build blocks after the main commitWork is completed and there are some new transactions which can be filled. Hence, we individually process these transactions as we receive them. Currently, we don't honour commit interrupt which means that a heavy transaction can consume lot of time.

Hence, before calling commit, we first check if we still have time to process using header's timestamp. If we do, we set the context with a timeout so that if it takes time to execute, we interrupt the process on time.

Changes

• Bugfix (non-breaking change that solves an issue)
• Hotfix (change that solves an urgent issue, and requires immediate attention)
• New feature (non-breaking change that adds functionality)
• Breaking change (change that is not backwards-compatible and/or changes current functionality)
• Changes only for a subset of nodes

Breaking changes

Please complete this section if any breaking changes have been made, otherwise delete it

Nodes audience

In case this PR includes changes that must be applied only to a subset of nodes, please specify how you handled it (e.g. by adding a flag with a default value...)

Checklist

• I have added at least 2 reviewer or the whole pos-v1 team
• I have added sufficient documentation in code
• I will be resolving comments - if any - by pushing each fix in a separate commit and linking the commit hash in the comment reply
• Created a task in Jira and informed the team for implementation in Erigon client (if applicable)
• Includes RPC methods changes, and the Notion documentation has been updated

Cross repository changes

• This PR requires changes to heimdall
  • In case link the PR here:
• This PR requires changes to matic-cli
  • In case link the PR here:

Testing

• I have added unit tests
• I have added tests to CI
• I have tested this code manually on local environment
• I have tested this code manually on remote devnet using express-cli
• I have tested this code manually on mumbai/amoy
• I have created new e2e tests into express-cli

Manual tests

Please complete this section with the steps you performed if you ran manual tests for this functionality, otherwise delete it

Additional comments

Please post additional comments in this section if you have them, otherwise delete it

[codecov]

Codecov Report

Attention: Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.

Project coverage is 50.36%. Comparing base (d1219ff) to head (9a0c826).

Files with missing lines	Patch %	Lines
miner/worker.go	66.66%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #1434   +/-   ##
========================================
  Coverage    50.36%   50.36%           
========================================
  Files          771      771           
  Lines       125119   125120    +1     
========================================
+ Hits         63013    63022    +9     
+ Misses       58099    58077   -22     
- Partials      4007     4021   +14     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cffls]

Would it be possible to add a test for it? Otherwise we might run into the same issue again in the future after refactoring.

[manav2401]

@cffls it's a bit difficult to test this via a unit test because every test is from a validator's perspective and one never receives the trigger to mine via the new transaction channel (because the w.running is set to true and the trigger is guarded by !w.IsRunning() check). Validator will always mine via normal newHead channel and produce blocks normally and then immediately commit block (without waiting for any more transactions even if there's time).

The fix above only applies to sentry and it's not possible to test it (at leasts from the worker module where we can access the low level functions).