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

BCFR-1087 Detect Finality Violation on Backfill #15825

Merged

Conversation

dhaidashenko
Copy link
Collaborator

@dhaidashenko dhaidashenko commented Jan 2, 2025

Improves detection of finality violations during backfill operation. DD
Test namespace load-ccip-d6901

Copy link
Contributor

github-actions bot commented Jan 2, 2025

I see you updated files related to core. Please run pnpm changeset in the root directory to add a changeset as well as in the text include at least one of the following tags:

  • #added For any new functionality added.
  • #breaking_change For any functionality that requires manual action for the node to boot.
  • #bugfix For bug fixes.
  • #changed For any change to the existing functionality.
  • #db_update For any feature that introduces updates to database schema.
  • #deprecation_notice For any upcoming deprecation functionality.
  • #internal For changesets that need to be excluded from the final changelog.
  • #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
  • #removed For any functionality/config that is removed.
  • #updated For any functionality that is updated.
  • #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

Copy link
Contributor

github-actions bot commented Jan 2, 2025

AER Report: CI Core ran successfully ✅

aer_workflow , commit

AER Report: Operator UI CI

aer_workflow , commit , Breaking Changes GQL Check

1. Workflow triggered downstream job failed: breaking-changes-gql-check

Source of Error:
Run convictional/trigger-workflow-and-wait@f69fa9eedd3c62a599220f4d5745230e237904be	2025-01-17T12:54:21.6221837Z Checking conclusion [failure]
Run convictional/trigger-workflow-and-wait@f69fa9eedd3c62a599220f4d5745230e237904be	2025-01-17T12:54:21.6222348Z Checking status [completed]
Run convictional/trigger-workflow-and-wait@f69fa9eedd3c62a599220f4d5745230e237904be	2025-01-17T12:54:21.6222977Z Conclusion is not success, it's [failure].
Run convictional/trigger-workflow-and-wait@f69fa9eedd3c62a599220f4d5745230e237904be	2025-01-17T12:54:21.6223465Z Propagating failure to upstream job

Why: The error indicates that the downstream workflow triggered by the convictional/trigger-workflow-and-wait action did not complete successfully. The conclusion of the downstream workflow was failure, which caused the upstream job to fail as well.

Suggested fix: Investigate the logs of the downstream workflow at the provided URL to identify the specific cause of the failure. Address the issue in the downstream workflow to ensure it completes successfully.

@dhaidashenko dhaidashenko marked this pull request as ready for review January 3, 2025 15:14
@dhaidashenko dhaidashenko requested review from a team as code owners January 3, 2025 15:14
core/chains/evm/logpoller/log_poller.go Outdated Show resolved Hide resolved
}

if err != nil {
lp.lggr.Errorw("Failed to poll and save logs, retrying later", "err", err)
Copy link
Collaborator

Choose a reason for hiding this comment

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

food for thought, should we track these errors using a more "observable" approach? For instance, by increasing a prometheus counter whenever pollAndSave or backup fails?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm not sure that it's really helpful to track this as a metric. Failures of pollAndSave and backup are normal (RPC failed for one of the requests), so we won't be using it on overview dashboards. We might want to introduce something of a higher level. Like the latest block successfully processed by LogPoller and compare it to one observed by HT or another component. High delta of these two values signals that PollAndSaved failed too often.
In any case it seems to be out of scope for this PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I think the "failed to poll and save logs due to finality violation" one is worth tracking, but as I understand it we're already tracking that indirectly because Healthy() will start returning false as soon as it happens. The other ones are fairly normal, will happen due to any sort of temporary network instability which presumably is also tracked elsewhere

@mateusz-sekara mateusz-sekara added this pull request to the merge queue Jan 20, 2025
Merged via the queue into develop with commit cb6565d Jan 20, 2025
167 of 169 checks passed
@mateusz-sekara mateusz-sekara deleted the fix/BCFR-1087-finality-violation-detection-sparse-fetch branch January 20, 2025 15:16
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.

4 participants