chore (supervisor): add metrics to reorg #2655
Conversation
itschaindev
requested review from
clabby,
dhyaniarun1993,
emhane,
refcell,
sadiq1971 and
theochap
as code owners
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've thoroughly reviewed this PR that adds metrics to the supervisor reorg functionality. Overall, the implementation follows good patterns but has some areas for improvement. Todo List:
✅ Strengths
🔍 Issues & Recommendations1. Time Calculation Bug (Critical)File: // Calculate latency
match SystemTime::now().duration_since(std::time::UNIX_EPOCH) {
Ok(duration) => {
let now = duration.as_secs_f64();
let latency = now - start_time;Problem: This assumes Recommendation: Use // In handler.rs
let start_time = std::time::Instant::now();
// In metrics.rs
let latency = start_time.elapsed().as_secs_f64();2. Error Handling in HandlerFile: Issue: Using Recommendation: Handle the error or use let start_time = match SystemTime::now().duration_since(std::time::UNIX_EPOCH) {
Ok(duration) => duration.as_secs_f64(),
Err(_) => {
warn!("Failed to get start time, using 0");
0.0
}
};3. Missing TestsFile: Issue: The new metrics module has no tests, unlike the existing Recommendation: Add tests for:
4. Potential Task Result Handling IssueFile: future::join_all(handles).await;Issue: Results from spawned tasks are being ignored. If a task fails, it won't be propagated. Recommendation: Handle the results: let results = future::join_all(handles).await;
for result in results {
if let Err(err) = result? {
error!("Reorg task failed: {:?}", err);
}
}5. Inconsistent Zero InitializationFile: Issue: The zero initialization doesn't pre-populate chain_id labels like other metrics modules in the codebase do. Recommendation: Consider adding a method to pre-initialize metrics for known chain IDs during startup. 🛡️ Security Assessment
⚡ Performance Considerations
🧪 Test Coverage Assessment
🔧 Minor Improvements
📋 SummaryThis is a solid implementation that adds valuable observability to the reorg functionality. The main issues are around error handling and test coverage. The time calculation approach works but could be simplified for better performance and clarity. Recommendation: ✅ Approve after addressing the critical time calculation and error handling issues |
Codecov Report❌ Patch coverage is ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed my comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Issues & Recommendations1. Missing Test Coverage (Important)File: Issue: The new metrics module has no tests, unlike other components that have comprehensive test coverage. Looking at other metrics modules in the codebase, they typically don't have unit tests, but the complex logic here (especially error handling) would benefit from testing. Recommendation: While not critical since other metrics modules lack tests, consider adding basic tests for:
2. Zero Initialization GapFile: Issue: Unlike other metrics modules (e.g., Recommendation: Consider adding a method to pre-initialize metrics for known chain IDs: pub(crate) fn init_for_chain(chain_id: ChainId) {
Self::describe();
Self::zero_for_chain(chain_id);
}
fn zero_for_chain(chain_id: ChainId) {
let chain_id_str = chain_id.to_string();
metrics::counter!(Self::SUPERVISOR_L1_REORG_SUCCESS_TOTAL, "chain_id" => chain_id_str.clone()).increment(0);
metrics::counter!(Self::SUPERVISOR_L1_REORG_ERROR_TOTAL, "chain_id" => chain_id_str.clone()).increment(0);
// ... etc
}3. Documentation MissingFile: Issue: Public methods lack rustdoc comments, unlike other modules in the codebase. Recommendation: Add rustdoc comments to public methods: /// Records metrics for L1 reorg processing operations.
///
/// # Arguments
/// * `chain_id` - The chain ID being processed
/// * `start_time` - When the reorg processing started
/// * `result` - The result containing reorg depths or error
pub(crate) fn record_l1_reorg_processing(/* ... */) {🛡️ Security Assessment
⚡ Performance Considerations
📊 Code Quality AssessmentExcellent Improvements:
Minor Areas:
🧪 Test Coverage Assessment
📋 SummaryThis is a well-implemented addition that significantly improves observability for reorg operations. The implementation has been substantially improved from earlier versions, particularly fixing the time calculation issues and improving error handling. Key Improvements Made:
Remaining Minor Issues:
Recommendation: ✅ Approve - This is production-ready code that follows project conventions and provides valuable observability without introducing any bugs or security issues. |
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed my comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Issues & Recommendations1. Missing Test Coverage (Moderate Priority)File: Issue: The new metrics module has no unit tests. While this is consistent with other metrics modules in the codebase (e.g., Recommendation: Consider adding basic tests for:
2. Zero Initialization GapFile: Issue: Unlike Comparison: // chain_processor/metrics.rs (good pattern)
fn zero(chain_id: ChainId) {
Self::zero_block_processing(chain_id, Self::BLOCK_TYPE_LOCAL_UNSAFE);
// ... for each block type
}
// reorg/metrics.rs (current - no chain_id labels)
fn zero() {
metrics::counter!(Self::SUPERVISOR_L1_REORG_SUCCESS_TOTAL,).increment(0);
// ...
}Recommendation: Consider following the chain_processor pattern: pub(crate) fn init_for_chain(chain_id: ChainId) {
Self::describe();
Self::zero_for_chain(chain_id);
}
fn zero_for_chain(chain_id: ChainId) {
let chain_id_str = chain_id.to_string();
metrics::counter!(Self::SUPERVISOR_L1_REORG_SUCCESS_TOTAL, "chain_id" => chain_id_str.clone()).increment(0);
// ... etc
}3. Documentation MissingFile: Issue: Public methods lack rustdoc comments, while the codebase generally has good documentation practices. Recommendation: Add rustdoc comments: /// Records metrics for L1 reorg processing operations.
///
/// # Arguments
/// * `chain_id` - The chain ID being processed
/// * `start_time` - When the reorg processing started
/// * `result` - The result containing reorg depths or error
pub(crate) fn record_l1_reorg_processing(/* ... */) {🛡️ Security Assessment
⚡ Performance Considerations
📊 Code Quality AssessmentExcellent Improvements from Previous Reviews:
Technical Excellence:
🧪 Test Coverage Assessment
📋 SummaryThis is an excellent implementation that significantly enhances observability for reorg operations. The code quality is high, follows project conventions, and introduces no bugs or security issues. Key Strengths:
Minor Areas for Improvement:
Recommendation: ✅ Approve - This is production-ready code that provides valuable observability improvements without introducing any significant issues. The minor recommendations are enhancements rather than blockers. |
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed a comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Areas for Improvement1. Zero Initialization Inconsistency (Moderate Priority)File: Issue: The current zero initialization doesn't pre-populate chain_id labels, which is inconsistent with other metrics modules like Comparison: // chain_processor/metrics.rs (follows best practice)
fn zero(chain_id: ChainId) {
Self::zero_block_processing(chain_id, Self::BLOCK_TYPE_LOCAL_UNSAFE);
// ... for each block type with chain_id labels
}
// reorg/metrics.rs (current - no chain_id labels)
fn zero() {
metrics::counter!(Self::SUPERVISOR_L1_REORG_SUCCESS_TOTAL,).increment(0);
// ... no chain_id labels
}Impact: This could result in missing baseline metrics for chains that haven't experienced reorgs yet. Recommendation: Follow the established pattern: pub(crate) fn init(chain_id: ChainId) {
Self::describe();
Self::zero(chain_id);
}
fn zero(chain_id: ChainId) {
let chain_id_str = chain_id.to_string();
metrics::counter!(Self::SUPERVISOR_L1_REORG_SUCCESS_TOTAL, "chain_id" => chain_id_str.clone()).increment(0);
metrics::counter!(Self::SUPERVISOR_L1_REORG_ERROR_TOTAL, "chain_id" => chain_id_str.clone()).increment(0);
// ... etc
}2. Missing Documentation (Low Priority)File: Issue: Public methods lack rustdoc comments, while other modules in the codebase generally have good documentation. Recommendation: Add rustdoc comments: /// Records metrics for L1 reorg processing operations.
///
/// # Arguments
/// * `chain_id` - The chain ID being processed
/// * `start_time` - When the reorg processing started
/// * `result` - The result containing reorg depths or error
pub(crate) fn record_l1_reorg_processing(/* ... */) {3. Test Coverage Gap (Low Priority)File: Issue: The new metrics module has no unit tests. While this is consistent with other metrics modules in the codebase (e.g., Recommendation: Consider adding basic tests for:
🛡️ Security Assessment
⚡ Performance Assessment
📊 Code Quality AssessmentTechnical Excellence:
Code Consistency:
🧪 Test Coverage Assessment
📋 SummaryThis is a high-quality implementation that significantly improves observability for reorg operations. The code quality is excellent, follows all project conventions, and introduces no bugs or security issues. Key Strengths:
Minor Recommendations:
Recommendation: ✅ Approve - This is production-ready code that provides valuable observability improvements. The implementation quality is high, and any remaining items are minor enhancements rather than blockers. |
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed my comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Issues & Recommendations1. Missing Test Coverage (Important)Files: Issue: The new metrics module has no unit tests, and the codecov report shows 0% coverage for this file (61 missing lines). While other metrics modules in the codebase also lack tests, the complex error handling logic here would benefit from testing. Recommendation: Consider adding basic tests for:
2. Inconsistent Zero Initialization PatternFile: Issue: Unlike Comparison: // chain_processor/metrics.rs (established pattern)
fn zero(chain_id: ChainId) {
Self::zero_block_processing(chain_id, Self::BLOCK_TYPE_LOCAL_UNSAFE);
// ... for each type with chain_id labels
}
// reorg/metrics.rs (current - no chain_id labels)
fn zero() {
metrics::counter!(Self::SUPERVISOR_L1_REORG_SUCCESS_TOTAL,).increment(0);
// ... without chain_id labels
}Recommendation: Follow the established pattern for consistency: pub(crate) fn init(chain_id: ChainId) {
Self::describe();
Self::zero(chain_id);
}
fn zero(chain_id: ChainId) {
let chain_id_str = chain_id.to_string();
metrics::counter!(Self::SUPERVISOR_L1_REORG_SUCCESS_TOTAL, "chain_id" => chain_id_str.clone()).increment(0);
// ... etc
}3. Missing DocumentationFile: Issue: Public methods lack rustdoc comments, which is inconsistent with project documentation standards. Recommendation: Add rustdoc comments: /// Records metrics for L1 reorg processing operations.
///
/// # Arguments
/// * `chain_id` - The chain ID being processed
/// * `start_time` - When the reorg processing started
/// * `result` - The result containing reorg depths or error
pub(crate) fn record_l1_reorg_processing(/* ... */) {🛡️ Security Assessment
⚡ Performance Considerations
📊 Code Quality AssessmentTechnical Excellence:
Follows Project Standards:
🧪 Test Coverage Assessment
📋 SummaryThis is an excellent implementation that significantly enhances observability for reorg operations. The code quality is high, follows project conventions, and introduces no bugs or security issues. Key Improvements:
Minor Enhancement Opportunities:
Recommendation: ✅ Approve - This is production-ready code that provides valuable observability improvements without introducing any significant issues. The identified areas are minor enhancements rather than blockers, and the implementation demonstrates strong engineering practices and attention to detail. |
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed my comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Issues & Recommendations1. Missing Test Coverage (Important)Files: Issue: The new metrics module has no unit tests, and the codecov report shows 0% coverage for this file (60 missing lines). While other metrics modules in the codebase also lack tests, the complex error handling logic here would benefit from testing. Recommendation: Consider adding basic tests for:
2. Inconsistent Zero Initialization PatternFile: Issue: Unlike Comparison: // chain_processor/metrics.rs (established pattern)
fn zero(chain_id: ChainId) {
Self::zero_block_processing(chain_id, Self::BLOCK_TYPE_LOCAL_UNSAFE);
Self::zero_block_processing(chain_id, Self::BLOCK_TYPE_CROSS_UNSAFE);
// ... for each type with chain_id labels
}
// reorg/metrics.rs (current - simpler but less comprehensive)
fn zero(chain_id: ChainId) {
metrics::counter!(Self::SUPERVISOR_REORG_SUCCESS, "chain_id" => chain_id.to_string())
.increment(0);
// ... without pre-population of all expected metrics
}Recommendation: The current approach is actually simpler and more appropriate for reorg metrics. However, consider following the 3. Missing DocumentationFile: Issue: Public methods lack rustdoc comments, which is inconsistent with project documentation standards. Recommendation: Add rustdoc comments: /// Records metrics for L1 reorg processing operations.
///
/// # Arguments
/// * `chain_id` - The chain ID being processed
/// * `start_time` - When the reorg processing started
/// * `result` - The result containing reorg depths or error
pub(crate) fn record_l1_reorg_processing(/* ... */) {🛡️ Security Assessment
⚡ Performance Considerations
📊 Code Quality AssessmentTechnical Excellence:
Follows Project Standards:
🧪 Test Coverage Assessment
📋 SummaryThis is an excellent implementation that significantly enhances observability for reorg operations. The code quality is high, follows project conventions, and introduces no bugs or security issues. Key Improvements:
Minor Enhancement Opportunities:
Recommendation: ✅ Approve - This is production-ready code that provides valuable observability improvements without introducing any significant issues. The identified areas are minor enhancements rather than blockers, and the implementation demonstrates strong engineering practices and attention to detail. |
itschaindev
added
M-metrics
emhane
left a comment
emhane
left a comment
There was a problem hiding this comment.
the scope of this pr is a bit low cohesion, asides that super nice!
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed my comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Issues & Concerns1. Scope Cohesion Issues (Critical - Addresses Reviewer Feedback)The reviewer correctly identified scope issues. This PR mixes metrics implementation with unrelated changes: ❌ Docker Changes Unrelated to Metrics:
❌ Task.rs Changes Beyond Metrics:
2. Import Organization (Moderate - Reviewer Feedback)File: Issue: Current: use super::metrics::Metrics;
// ... later usage
Metrics::record_l1_reorg_processing(chain_id, start_time, &result);Recommendation: Follow the suggestion and import Metrics in the prelude for cleaner usage. 3. Inconsistent Error Handling (Moderate - Reviewer Feedback)File: Issue: The reviewer asks whether the error logging should differentiate between supervisor program errors vs individual chain errors. Current: for result in results {
if let Err(err) = result {
warn!(target: "supervisor::reorg_handler", %err, "Reorg task failed");
}
}Recommendation: Match on the error type and log accordingly:
4. Metrics Uniformity (Important - Reviewer Feedback)File: Issue: Inconsistent constant organization across supervisor modules. Comparison: // storage/metrics.rs (scoped in impl)
impl Metrics {
pub(crate) const STORAGE_REQUESTS_SUCCESS_TOTAL: &'static str = "...";
// reorg/metrics.rs (also scoped in impl) ✅
impl Metrics {
pub(crate) const SUPERVISOR_REORG_SUCCESS: &'static str = "...";
// chain_processor/metrics.rs (also scoped in impl) ✅
impl Metrics {
pub(crate) const BLOCK_PROCESSING_SUCCESS_TOTAL: &'static str = "...";Assessment: The reorg metrics actually follows the established pattern correctly. All supervisor metrics modules scope constants within the impl block. 5. Missing Test Coverage (Important)File: Issue: 0% test coverage according to codecov (65 missing lines). The complex error handling logic would benefit from basic testing. Recommendation: Add tests for:
6. Zero Initialization CompletenessFile: Analysis: Comparing with other modules:
Assessment: The current approach is simpler and appropriate for reorg metrics, but could be more comprehensive for consistency. 🛡️ Security Assessment
⚡ Performance Assessment
📊 Code Quality AssessmentGood Practices:
Areas for Improvement:
🧪 Test Coverage
📋 Summary & RecommendationsThis is a solid metrics implementation with good architectural patterns, but has scope and consistency issues raised by the reviewer. Critical Actions Required:
Recommended Improvements:
Reviewer Feedback Status:
Recommendation: 🔄 Address reviewer feedback first, then this will be ready for approval. The core metrics implementation is well-designed but needs scope cleanup. |
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed my comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Issues & Recommendations1. Missing Test Coverage (Important)File: Issue: The new metrics module has no unit tests. While other metrics modules in the codebase (like Recommendation: Consider adding basic tests for:
2. Potential JoinHandle Result Handling IssueFile: Issue: The current error handling logs Current: for result in results {
if let Err(err) = result {
warn!(target: "supervisor::reorg_handler", %err, "Reorg task failed");
}
}Recommendation: Consider unwrapping the inner result to differentiate between tokio join errors and actual reorg processing errors: for result in results {
match result {
Ok(Ok(_)) => {} // Success
Ok(Err(reorg_err)) => {
warn!(target: "supervisor::reorg_handler", %reorg_err, "Reorg processing failed for chain");
}
Err(join_err) => {
error!(target: "supervisor::reorg_handler", %join_err, "Reorg task panicked or was cancelled");
}
}
}3. Zero Initialization PatternFile: Analysis: Comparing with other metrics modules:
Assessment: The current approach is actually appropriate for reorg metrics since there aren't multiple sub-types like in other modules. The implementation is consistent and clean. 4. Documentation GapFile: Issue: Public methods lack rustdoc comments, which is inconsistent with project documentation standards. Recommendation: Add rustdoc comments: /// Records metrics for L1 reorg processing operations.
///
/// # Arguments
/// * `chain_id` - The chain ID being processed
/// * `start_time` - When the reorg processing started
/// * `result` - The result containing reorg depths or error
pub(crate) fn record_l1_reorg_processing(/* ... */) {🛡️ Security Assessment
⚡ Performance Assessment
📊 Code Quality AssessmentTechnical Excellence:
Follows Project Standards:
🧪 Test Coverage Assessment
📋 Addressing Reviewer Feedback✅ Scope Cohesion: The PR now has good scope cohesion focused on metrics implementation. Previous unrelated changes appear to have been addressed. ✅ Import Organization: ✅ Metrics Uniformity: The implementation correctly follows the established pattern with constants scoped within the impl block, consistent with other supervisor metrics modules. 📋 SummaryThis is an excellent implementation that significantly enhances observability for reorg operations. The code quality is high, follows project conventions, and introduces no bugs or security issues. Key Improvements:
Minor Enhancement Opportunities:
Recommendation: ✅ Approve - This is production-ready code that provides valuable observability improvements without introducing any significant issues. The identified areas are minor enhancements rather than blockers, and the implementation demonstrates strong engineering practices. |
segregated the changes into a different pr. [Ref](#2655 (comment))
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed my comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Issues & Recommendations1. Missing Test Coverage (Important)File: Issue: The new metrics module has no unit tests, and the codecov report shows 0% coverage for this file (65 missing lines). While other metrics modules in the codebase also lack tests, the complex error handling logic here would benefit from testing. Recommendation: Consider adding basic tests for:
2. Potential JoinHandle Result Handling IssueFile: Issue: The current error handling logs Current: for result in results {
if let Err(err) = result {
warn!(target: "supervisor::reorg_handler", %err, "Reorg task failed");
}
}Recommendation: Consider unwrapping the inner result to differentiate between tokio join errors and actual reorg processing errors: for result in results {
match result {
Ok(Ok(_)) => {} // Success
Ok(Err(reorg_err)) => {
warn!(target: "supervisor::reorg_handler", %reorg_err, "Reorg processing failed for chain");
}
Err(join_err) => {
error!(target: "supervisor::reorg_handler", %join_err, "Reorg task panicked or was cancelled");
}
}
}3. Zero Initialization PatternFile: Analysis: Comparing with other metrics modules:
Assessment: The current approach is actually appropriate for reorg metrics since there aren't multiple sub-types like in other modules. The implementation is consistent and clean. 4. Documentation GapFile: Issue: Public methods lack rustdoc comments, which is inconsistent with project documentation standards. Recommendation: Add rustdoc comments: /// Records metrics for L1 reorg processing operations.
///
/// # Arguments
/// * `chain_id` - The chain ID being processed
/// * `start_time` - When the reorg processing started
/// * `result` - The result containing reorg depths or error
pub(crate) fn record_l1_reorg_processing(/* ... */) {🛡️ Security Assessment
⚡ Performance Assessment
📊 Code Quality AssessmentTechnical Excellence:
Follows Project Standards:
🧪 Test Coverage Assessment
📋 Addressing Previous Reviewer FeedbackLooking at the review comments from @emhane:
📋 SummaryThis is an excellent implementation that significantly enhances observability for reorg operations. The code quality is high, follows project conventions, and introduces no bugs or security issues. Key Improvements:
Minor Enhancement Opportunities:
Recommendation: ✅ Approve - This is production-ready code that provides valuable observability improvements without introducing any significant issues. The identified areas are minor enhancements rather than blockers, and the implementation demonstrates strong engineering practices. |
|
Claude finished @itschaindev's task —— View job PR Review: Add metrics to reorgI've completed my comprehensive review of this PR that adds metrics to the supervisor reorg functionality. Todo List:
✅ Strengths
🔍 Issues & Recommendations1. Missing Test Coverage (Important)File: Issue: The new metrics module has no unit tests, and the codecov report shows 0% coverage for this file (65 missing lines). While other metrics modules in the codebase (like Recommendation: Consider adding basic tests for:
2. Addressing Reviewer Feedback on Result HandlingFile: Issue: @emhane's feedback about error differentiation is valid. The current error handling logs Current: for result in results {
if let Err(err) = result {
warn!(target: "supervisor::reorg_handler", %err, "Reorg task failed");
}
}Recommendation: Consider unwrapping the inner result to differentiate between tokio join errors and actual reorg processing errors: for result in results {
match result {
Ok(Ok(_)) => {} // Success
Ok(Err(reorg_err)) => {
warn!(target: "supervisor::reorg_handler", %reorg_err, "Reorg processing failed for chain");
}
Err(join_err) => {
error!(target: "supervisor::reorg_handler", %join_err, "Reorg task panicked or was cancelled");
}
}
}3. Consider Struct Return Type for TupleFile: Issue: @emhane's latest feedback suggests defining a new struct for the return type instead of using Current: Assessment: The current 4. Import OrganizationFile: Issue: @emhane suggested bringing Current: Assessment: The current approach is fine, but could be moved to prelude if preferred for consistency with other modules. 5. Documentation GapFile: Issue: Public methods lack rustdoc comments, which is inconsistent with project documentation standards. Recommendation: Add rustdoc comments: /// Records metrics for L1 reorg processing operations.
///
/// # Arguments
/// * `chain_id` - The chain ID being processed
/// * `start_time` - When the reorg processing started
/// * `result` - The result containing reorg depths or error
pub(crate) fn record_l1_reorg_processing(/* ... */) {🛡️ Security Assessment
⚡ Performance Assessment
📊 Code Quality AssessmentTechnical Excellence:
Follows Project Standards:
Comparison with Existing Metrics Modules:
🧪 Test Coverage Assessment
📋 Addressing Previous ReviewsLooking at the extensive review history, this PR has evolved significantly and addresses most previous concerns: ✅ Scope Cohesion: Current PR has excellent scope focused solely on metrics implementation 📋 SummaryThis is an excellent implementation that significantly enhances observability for reorg operations. The code quality is high, follows project conventions, and introduces no bugs or security issues. Key Improvements Made:
Minor Enhancement Opportunities:
Recommendation: ✅ Approve - This is production-ready code that provides valuable observability improvements without introducing any significant issues. The identified areas are minor enhancements rather than blockers, and the implementation demonstrates strong engineering practices. The latest reviewer feedback about struct vs tuple is already well-addressed by the existing |
segregated the changes into a different pr. [Ref](op-rs/kona#2655 (comment))
segregated the changes into a different pr. [Ref](op-rs/kona#2655 (comment))
segregated the changes into a different pr. [Ref](op-rs/kona#2655 (comment))
segregated the changes into a different pr. [Ref](op-rs/kona#2655 (comment))
3 participants
Closes #2499