ci(ctb): don't fail ci on snapshot diff#3021
Merged
mergify[bot] merged 1 commit intodevelopfrom Jul 13, 2022
Merged
Conversation
|
tynes
approved these changes
Jul 13, 2022
smartcontracts
approved these changes
Jul 13, 2022
Contributor
|
This PR has been added to the merge queue, and will be merged soon. |
Contributor
|
This PR is next in line to be merged, and will be merged as soon as checks pass. |
theochap
pushed a commit
that referenced
this pull request
Dec 10, 2025
#3018) # Description The main goal of this change is to allow engine processing to continue after block building has been initiated but before it has been sealed. This is accomplished by: - Updating the `EngineActor` to - Make the `BuildTask` only initiate block building - Add a new `SealTask` to seal and insert the initiated block - Updating the `SequencerActor` loop to - Seal the last block and start the next block - Dynamically set the loop interval to account for sealing duration Importantly the `SequencerActor`'s `build_block` function no longer starts and completes block building in a single call but rather seals the last block if there was one, and starts the next. This means that the time spent waiting for the next tick will be _during block building_. This also changes the `EngineTask` pattern within the `SealTask` such that if there was a caller (i.e. there exists a `Sender` to use to relay results), the task may not be retried if there is a "temporary" task error. While this diverges from existing patterns, it is a meaningful step toward #3021, which aims to pull logic out of the engine and into the appropriate actor. This gives the Sequencer more insight into and control over block building and timing. ## Considerations This PR creates a number of possible race conditions. One race condition that did not previously exist but has been introduced and mitigated is `Build` (FCU) -> `Reset` -> `Seal`. A worthwhile exercise for a reviewer is to consider the other possible race conditions introduced and evaluate the feasibility of them occurring and impact if they happen. ## Testing While this PR is ready to review and passes existing e2e and acceptance tests, a byproduct of breaking apart the `BuildTask` is a number of possible race conditions. This PR aimed to address a number of them (e.g. detecting if the unsafe head changed between `Build` and `Seal` operations and retrying), but a worthwhile exercise will be to: 1. List all possible `EngineActor` task race conditions that could result from this change 1. Define expected behavior for each of those conditions 1. Confirm via unit tests that behavior matches expected behavior. There is also value in unit testing the logic in the different functions within `SequencerActor` and the affected `EngineActor` tasks. Unfortunately the act of making the `SequencerActor`, `EngineActor`, and `EngineTask`s unit testable is a considerable amount of work. A different PR will be created, branching off of this PR to attempt that. This PR _can_ be merged as is, as it meets current standards, but another reasonable option is to wait until `kona` is more unit testable and unit tests exist to demonstrate that the changes work as intended. ## Other Fixes #2978 Relates to #2848, #3021
theochap
pushed a commit
that referenced
this pull request
Dec 10, 2025
# Summary This PR makes a number of actor-framework-level changes to allow dependency injection and ultimately unit tests within all of the actors. The actor that is used to demonstrate the updates is `SequencerActor`. If this approach looks good, issues can be created to update other actors and add test coverage. This also starts to create client traits for different actor functionality in an effort to remove channel dependencies at the interface level. This will help streamline unit tests and allow the interfaces to evolve more seamlessly. ## Key Changes * Loosen `NodeActor` trait requirements (remove `build()` fn and `builder` type) * Remove `RollupNodeService` trait since it had one implementation and logic split between trait and impl * Create traits for _most_ `SequencerActor` dependencies * This includes making facade client traits for actor-actor communication, loosening the interface-level dependence on channels and increasing unit testing ergonomics * The remaining dependencies will be wrapped in traits as a follow-up PR to this one to avoid further bulking this PR * Make `SequencerActor` generic over dependency traits * Inject concrete instances of dependencies into `SequencerActor` * Separate logic in `SequencerActor` into helper functions for better readability and self-documentation * Pull metrics, admin api server, error, and builder utilities into separate files to self-document and reduce size of main `SequencerActor` file --- Ref: #3025, #3021, #2623
theochap
pushed a commit
that referenced
this pull request
Jan 14, 2026
op-rs/kona#3018) # Description The main goal of this change is to allow engine processing to continue after block building has been initiated but before it has been sealed. This is accomplished by: - Updating the `EngineActor` to - Make the `BuildTask` only initiate block building - Add a new `SealTask` to seal and insert the initiated block - Updating the `SequencerActor` loop to - Seal the last block and start the next block - Dynamically set the loop interval to account for sealing duration Importantly the `SequencerActor`'s `build_block` function no longer starts and completes block building in a single call but rather seals the last block if there was one, and starts the next. This means that the time spent waiting for the next tick will be _during block building_. This also changes the `EngineTask` pattern within the `SealTask` such that if there was a caller (i.e. there exists a `Sender` to use to relay results), the task may not be retried if there is a "temporary" task error. While this diverges from existing patterns, it is a meaningful step toward #3021, which aims to pull logic out of the engine and into the appropriate actor. This gives the Sequencer more insight into and control over block building and timing. ## Considerations This PR creates a number of possible race conditions. One race condition that did not previously exist but has been introduced and mitigated is `Build` (FCU) -> `Reset` -> `Seal`. A worthwhile exercise for a reviewer is to consider the other possible race conditions introduced and evaluate the feasibility of them occurring and impact if they happen. ## Testing While this PR is ready to review and passes existing e2e and acceptance tests, a byproduct of breaking apart the `BuildTask` is a number of possible race conditions. This PR aimed to address a number of them (e.g. detecting if the unsafe head changed between `Build` and `Seal` operations and retrying), but a worthwhile exercise will be to: 1. List all possible `EngineActor` task race conditions that could result from this change 1. Define expected behavior for each of those conditions 1. Confirm via unit tests that behavior matches expected behavior. There is also value in unit testing the logic in the different functions within `SequencerActor` and the affected `EngineActor` tasks. Unfortunately the act of making the `SequencerActor`, `EngineActor`, and `EngineTask`s unit testable is a considerable amount of work. A different PR will be created, branching off of this PR to attempt that. This PR _can_ be merged as is, as it meets current standards, but another reasonable option is to wait until `kona` is more unit testable and unit tests exist to demonstrate that the changes work as intended. ## Other Fixes #2978 Relates to #2848, #3021
theochap
pushed a commit
that referenced
this pull request
Jan 14, 2026
# Summary This PR makes a number of actor-framework-level changes to allow dependency injection and ultimately unit tests within all of the actors. The actor that is used to demonstrate the updates is `SequencerActor`. If this approach looks good, issues can be created to update other actors and add test coverage. This also starts to create client traits for different actor functionality in an effort to remove channel dependencies at the interface level. This will help streamline unit tests and allow the interfaces to evolve more seamlessly. ## Key Changes * Loosen `NodeActor` trait requirements (remove `build()` fn and `builder` type) * Remove `RollupNodeService` trait since it had one implementation and logic split between trait and impl * Create traits for _most_ `SequencerActor` dependencies * This includes making facade client traits for actor-actor communication, loosening the interface-level dependence on channels and increasing unit testing ergonomics * The remaining dependencies will be wrapped in traits as a follow-up PR to this one to avoid further bulking this PR * Make `SequencerActor` generic over dependency traits * Inject concrete instances of dependencies into `SequencerActor` * Separate logic in `SequencerActor` into helper functions for better readability and self-documentation * Pull metrics, admin api server, error, and builder utilities into separate files to self-document and reduce size of main `SequencerActor` file --- Ref: #3025, #3021, #2623
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.