refactor: try CN approach

[tac0turtle]

Overview

[claude]

Claude finished @tac0turtle's task —— View job

---

Comprehensive Code Review

I've completed my analysis of this P2P synchronization refactoring PR. This is a significant simplification that removes the notifier pattern (~663 lines deleted) in favor of a more direct "CN approach" (likely coordination/notification). Overall, this is a cleaner architecture with some excellent improvements, but there are several areas that warrant attention.

Todo List

• Gather context - read key changed files
• Analyze the refactoring approach and architectural changes
• Review concurrency patterns and synchronization logic
• Evaluate error handling and resilience
• Assess security implications
• Review performance and resource efficiency
• Analyze test coverage changes
• Provide comprehensive feedback

---

1. Code Quality & Architecture

Strengths ✅

• Excellent simplification: Removing the notifier package and its 518 test lines is a major win for maintainability. The old event-driven notification system added unnecessary indirection.
• Cleaner separation of concerns: The new p2pWorkerLoop approach is more direct and easier to reason about than subscription-based notifications.
• Better interface design: Changing from ProcessHeaderRange/ProcessDataRange to a single ProcessHeight that returns an error is more idiomatic Go.

Concerns ⚠️

1. Commented TODO needs resolution (block/internal/syncing/syncer.go:354-355):

// TODO @MARKO: why only if newDataHeight != newHeaderHeight? why not process// just if newDataHeight > currentHeight ?ifnewDataHeight!=newHeaderHeight&&newDataHeight>currentHeight {

This logic seems suspect and should be clarified before merge. If headers and data can arrive independently, this condition could skip valid data.

2. heightInCh buffer size may be excessive (syncer.go:107):

heightInCh: make(chan common.DAHeightEvent, 10_000),

A 10,000-element buffer is very large. As @alpe noted in review comments, the new p2pWorkerLoop design means the P2P handler can only move 1 message ahead of the consumer. Consider reducing this to 100-1000 to save memory while still providing adequate buffering.

3. Missing package documentation:
The P2PHandler and new coordination mechanisms lack godoc explaining the synchronization model.

---

2. Concurrency Patterns & Synchronization

###Strengths ✅

• Proper goroutine lifecycle: All workers are tracked via sync.WaitGroup with correct Add/Done patterns.
• Context cancellation: The p2pWaitState with cancellation context is a good pattern for interrupting blocked P2P fetches.
• Atomic operations: Use of atomic.Pointer and atomic.Uint64 for shared state is correct.

Concerns ⚠️

1. P2P handler timeout logic (p2p_handler.go:59-68):

timeoutCtx, cancel:=context.WithTimeout(ctx, 500*time.Millisecond)
header, err:=h.headerStore.GetByHeight(timeoutCtx, height)
cancel()
iferrors.Is(err, context.DeadlineExceeded) {
// Don't continue processing further heights if we timeout on onereturn
}

The old code processed ranges (ProcessHeaderRange) which made the early-return-on-timeout make sense. But the new ProcessHeight processes a single height, so the comment "Don't continue processing further heights" is misleading - there are no further heights to process. This comment should be updated.

2. Potential race in p2pWaitState (from diff):
The cancelP2PWait and setP2PWaitState/clearP2PWaitState functions use proper locking, but there's a subtle issue:

func (s*Syncer) cancelP2PWait(heightuint64) {
s.p2pWaitMu.Lock()
defers.p2pWaitMu.Unlock()
ifs.p2pWaitState.cancel!=nil&& (height==0||s.p2pWaitState.height==height) {
s.p2pWaitState.cancel()
s.p2pWaitState=p2pWaitState{}
}
}

When height == 0, this cancels any active wait. This is used in Stop() which is good. However, as @alpe suggested, you might also want to cancel when p2pWaitState.height <= height to handle cases where P2P is falling behind.

3. Missing concurrency protection in ProcessHeight:
P2PHandler.ProcessHeight updates processedHeight after sending to the channel:

h.mu.Lock()
ifheight>h.processedHeight {
h.processedHeight=height
}
h.mu.Unlock()

But if the channel send blocks (when buffer is full), there's a window where another goroutine could call ProcessHeight for the same height. Consider updating processedHeight before attempting the channel send, or use a select with default that also updates the counter.

---

3. Error Handling & Resilience

Strengths ✅

• Good error classification: The distinction between errInvalidBlock and errInvalidState with different handling strategies is well thought out.
• Critical error channel: Non-blocking sends to errorCh prevent deadlocks.
• DA backoff improvement: The recent commit "better da backoff" shows good iteration on retry logic.

Concerns ⚠️

1. Error handling inconsistency (syncer.go:351 - from review comments):
When GetByHeight returns an error for a height not yet available, should this really log an error? @alpe's review comment suggests ignoring "not found" errors here since it's expected when blocks haven't arrived yet. Consider:

iferr!=nil {
if!errors.Is(err, header.ErrNotFound) {
s.logger.Error().Err(err).Msg("failed to get current height")
}
return
}

2. Silent error swallowing in p2p_handler.go (lines 63-71, 86-94):

iferr!=nil {
iferrors.Is(err, context.DeadlineExceeded) {
h.logger.Debug().Uint64("height", height).Msg("timeout waiting for header from store, will retry later")
return
}
h.logger.Debug().Uint64("height", height).Err(err).Msg("failed to get header from store")
continue// THIS DOESN'T EXIST IN NEW CODE - it returns!
}

The new code returns the error, which is good, but callers must handle it. Ensure all call sites properly handle ProcessHeight errors.

3. Executor retry logic concerns (syncer.go:544-571):

forattempt:=1; attempt<=common.MaxRetriesBeforeHalt; attempt++ {
// ... execute ...iferr!=nil {
ifattempt==common.MaxRetriesBeforeHalt {
returnnil, fmt.Errorf("failed to execute transactions: %w", err)
}
// ... retry ...
}
returnnewAppHash, nil
}
returnnil, nil// This line is unreachable but returns nil, nil

The final return nil, nil is unreachable but misleading. Consider removing or adding a panic to document this is impossible.

---

4. Security

Strengths ✅

• Proposer validation: assertExpectedProposer prevents accepting blocks from unauthorized proposers.
• Data-header binding: The critical data commitment check (block/internal/syncing/p2p_handler.go:100-108) prevents accepting legitimate headers with tampered data. This is excellent.
• Signature verification: Custom verifier for aggregator node signatures is properly set before validation.

Concerns ⚠️

1. Potential DoS via pending event cache:
SetPendingEvent is called when the channel is full or when heights arrive out of order. There's no apparent limit on cache size. A malicious peer could send many future heights to exhaust memory. Verify that cache.Manager has size limits.

2. Error messages may leak internal state:

s.sendCriticalError(fmt.Errorf("invalid state detected (block-height %d, state-height %d) "+"- block references do not match local state. Manual intervention required: %w", ...))

While logging is necessary, ensure errorCh recipients don't expose these messages externally without sanitization.

---

5. Performance & Resource Efficiency

Strengths ✅

• Reduced allocations: Removing the notifier event system eliminates many small allocations.
• Direct channel communication: The new heightInCh approach is more efficient than event dispatching.
• Proper context timeouts: 500ms timeouts on P2P store fetches prevent indefinite blocking.

Concerns ⚠️

1. Excessive channel buffer (mentioned in Architecture section):
heightInCh: make(chan common.DAHeightEvent, 10_000) - reduce to 100-1000.

2. Busy-waiting in syncLoop (syncer.go:271-281):

s.processPendingEvents()
s.tryFetchFromP2P()
s.tryFetchFromDA(nextDARequestAt)
// Prevent busy-waiting when no events are processedselect {
case<-s.ctx.Done():
returncase<-time.After(min(10*time.Millisecond, s.config.Node.BlockTime.Duration)):
}

This sleeps for min(10ms, blockTime) on every iteration. If blockTime is small (e.g., 1ms), this still sleeps for 1ms even when events are being processed, adding unnecessary latency. Consider tracking whether any work was done and skipping the sleep if so.

3. Store.Height() called frequently:
processHeightEvent and tryFetchFromP2P both call s.store.Height(s.ctx) on every invocation. If this is a database query, consider caching it with invalidation on updates.

---

6. Testing & Reliability

Strengths ✅

• Good test coverage additions: New tests like TestP2PHandler_ProcessedHeightSkipsPreviouslyHandledBlocks verify the core coordination logic.
• Timeout tests: Tests use reasonable timeouts (50ms) to avoid flakiness.
• Mock simplification: Removing 126 lines from syncer_mock.go shows the interface is cleaner.

Concerns ⚠️

1. Significant test deletion (syncer_test.go: -180 lines):
While removing tests for the notifier is good, verify that equivalent coverage exists for the new coordination mechanism. The removed tests may have covered edge cases not present in the new tests.

2. Missing integration test for p2pWorkerLoop:
The new p2pWorkerLoop doesn't appear to have dedicated tests. Consider adding a test that verifies:

• Blocks correctly when height is unavailable
• Cancels wait when height becomes available from DA
• Respects context cancellation

3. Codecov shows 22 lines missing coverage:
Focus on:

• block/internal/syncing/syncer.go: 14 missing + 3 partials
• block/internal/syncing/p2p_handler.go: 3 missing
• pkg/sync/sync_service.go: 2 missing

---

7. Documentation

Concerns ⚠️

1. No package-level documentation update:
The architecture changed significantly but no README or doc comments explain the new "CN approach" vs the old notifier pattern.

2. Function comments need updates:

• tryFetchFromP2P still says "Returns true if any events were successfully processed" but it returns void.
• p2pWorkerLoop lacks documentation explaining its coordination with other workers.

3. The p2pWaitState pattern should be documented:
This is a clever coordination mechanism but has zero documentation. Add comments explaining:

• Why it exists (unblock P2P wait when DA provides the block)
• Thread-safety guarantees
• When cancel is called vs when state is cleared

---

Recommendations

High Priority 🔴

1. Resolve the TODO at syncer.go:354 - the data processing logic may be buggy
2. Reduce heightInCh buffer from 10,000 to 100-1000 (as @alpe suggested)
3. Add ErrNotFound handling in tryFetchFromP2P (per @alpe's comment at syncer.go:351)
4. Verify cache size limits to prevent DoS via pending events
5. Add p2pWorkerLoop integration test

Medium Priority 🟡

1. Consider @alpe's suggestion to cancel P2P wait when p2pWaitState.height <= height
2. Update misleading comments in p2p_handler.go about "further heights"
3. Document the p2pWaitState coordination pattern
4. Audit all ProcessHeight error handling call sites
5. Fix or remove unreachable return nil, nil in executeTxsWithRetry

Low Priority 🟢

1. Add package-level documentation for the new architecture
2. Consider caching store.Height() if it's expensive
3. Optimize busy-wait in syncLoop to skip sleep when processing events
4. Update tryFetchFromP2P doc comment (says it returns bool, but returns void)

---

Summary

This refactoring is a net positive - the removal of the notifier pattern significantly improves code clarity and maintainability. The new direct coordination approach is easier to understand and debug.

However, the PR has some rough edges that should be addressed:

• The unresolved TODO suggests incomplete analysis
• Several review comments from @alpe indicate optimization opportunities
• Error handling could be more precise
• Documentation lags behind the implementation

Recommendation: Address the high-priority items, particularly the TODO and buffer size optimization, before considering this production-ready. The medium-priority items would further improve robustness.

---

[github-actions]

The latest Buf updates on your PR. Results from workflow CI and Release / buf-check (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	✅ passed	✅ passed	Nov 6, 2025, 9:50 AM

[codecov]

Codecov Report

❌ Patch coverage is 81.51261% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.41%. Comparing base (b3f0a90) to head (568a988).
⚠️ Report is 10 commits behind head on marko/p2p_refactor.

Files with missing lines	Patch %	Lines
block/internal/syncing/syncer.go	81.31%	14 Missing and 3 partials ⚠️
block/internal/syncing/p2p_handler.go	85.71%	3 Missing ⚠️
pkg/sync/sync_service.go	50.00%	2 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## marko/p2p_refactor #2812 +/- ##
======================================================
+ Coverage 64.33% 64.41% +0.08% 
======================================================
Files 81 80 -1 Lines 7250 7147 -103 ======================================================
- Hits 4664 4604 -60 + Misses 2044 2007 -37 + Partials 542 536 -6 

Flag	Coverage Δ
combined	64.41% <81.51%> (+0.08%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[julienrbrt]

I generally prefer this over the notifer and current main. The simplification makes sense to me.

[alpe]

Very nice work. Much cleaner code and easier to follow.
With the changes, I believe that we can reduce heightInCh size to save some memory.
The P2P loop can only move 1 message ahead of the consumer now.

[alpe]

I would assume that we run into this quite often when the height is not available, yet. IMHO it is worth to ignore the not found error

[tac0turtle]

if a height it not available then we block on waiting for it. should not get hit unless we have a different issue.

[alpe]

IMHO it would be safe to cancel p2pWaitState.height <= height, just in case p2p is falling behind

[alpe]

Just wondering, is the height important? There should not be concurrent calls

[alpe]

personal preference: cancelP2PWait could be used to clear the state

[alpe]

Would it also make sense to cancel in the error case? We have the block in the cache now. 🤔 But the p2p handler height was not updated so it would return the block again