• block/alerts.go (1 hunks)
• block/manager.go (6 hunks)
• block/manager_test.go (2 hunks)
• cmd/rollkit/commands/alerts.go (1 hunks)
• cmd/rollkit/main.go (1 hunks)
• node/full.go (1 hunks)
• node/full_client.go (1 hunks)
• node/light.go (2 hunks)
• node/node.go (2 hunks)
• rpc/json/service.go (3 hunks)
• rpc/json/types.go (2 hunks)
• types/alerter.go (1 hunks)
• types/alerter_test.go (1 hunks)

cmd/rollkit/main.go (1)

• 19-19: The addition of AlertsCmd to the CLI's root command is correctly implemented and integrates the new alerts functionality into the CLI.

node/node.go (1)

• 24-24: Adding the Alerts() method to the Node interface is a significant enhancement for alerting capabilities. Ensure all implementations of the Node interface are updated to include this new method.

cmd/rollkit/commands/alerts.go (1)

• 22-22: Acknowledging the TODO comment about making the HTTP request more generic as a positive indication of planned improvements for maintainability.

types/alerter_test.go (1)

• 9-118: The tests for marshaling/unmarshaling AlertSeverity and the functionality of the Alerter interface are well-implemented and provide comprehensive coverage. Good job ensuring the new functionality is thoroughly tested.

types/alerter.go (1)

• 1-203: The introduction of the Alerter interface, Alert and GenericAlerter types, and related constants and methods are well-implemented and align with the PR's objectives to enhance alerting capabilities across the system. The design and implementation of these components provide a robust framework for managing alerts.

rpc/json/service.go (1)

• 89-89: The addition of the "alerts" method to the service's method map follows the established pattern and is correctly implemented.

block/manager_test.go (2)

• 36-36: The initialization of the alerter field in the getManager function is correctly implemented and follows the expected pattern for adding alerting capabilities.
• 483-550: The implementation of the TestSubmitBlocksToDAAlerts test function is well-structured and effectively tests the alerting behavior during block submission to the DA layer. It correctly simulates submission failures and successes and verifies the generated alerts.

block/manager.go (5)

• 65-66: The addition of the daSubmissionFailureLog constant is a good practice for consistent logging of DA layer submission failures.
• 125-126: The addition of the alerter field to the Manager struct is crucial for integrating the alerter system. Ensure that the alerter is properly initialized and utilized throughout the component.
• 266-266: Initialization of the alerter in the NewManager function is correctly done. Ensure that the NewAlerter function properly handles any initialization errors and that the "block_manager" identifier is used appropriately.
• 957-960: Handling of DA layer submission failures in submitBlocksToDA by registering an alert is a critical update for enhancing monitoring and alerting capabilities. Ensure that the alert severity and logging are appropriate for the failure event.
• 911-913: Unregistration of alerts upon successful submission in submitBlocksToDA is important for maintaining the accuracy of the monitoring system. Verify that the unregistration does not inadvertently affect other unrelated alerts.

• cmd/rollkit/commands/alerts.go (1 hunks)
• rpc/json/types.go (2 hunks)

• cmd/rollkit/commands/alerts.go
• rpc/json/types.go