feat: l1infotree publish GER reorged

[joanestebanr]

🔄 Changes Summary

• [Brief description of what was added, fixed, or changed in this PR]

⚠️ Breaking Changes

• 🛠️ Config: [Optional: Changes to TOML config]
• 🔌 API/CLI: [Optional: Breaking interface changes]
• 🗑️ Deprecated Features: [Optional: Removed features]

📋 Config Updates

• 🧾 Diff/Config snippet: [Optional: Enumerate config changes/provide snippet of changes]

✅ Testing

• 🤖 Automatic: [Optional: Enumerate E2E tests]
• 🖱️ Manual: [Optional: Steps to verify]

🐞 Issues

• Closes feat: Faster detection GER reorged #1482

🔗 Related PRs

• [Optional: Enumerate related pull requests]

📝 Notes

• [Optional: design decisions, tradeoffs, or TODOs]

[claude]

Claude finished @joanestebanr's task in 1m 15s —— View job

---

PR Review: feat: l1infotree publish GER reorged

Todo List

• Read changed files to understand implementation
• Analyze code diff against develop branch
• Review code quality and best practices
• Check for potential bugs and security issues
• Evaluate test coverage
• Provide structured feedback
• Complete summary template

---

🚀 What's New

This PR introduces a pub/sub notification system for GER (Global Exit Root) reorgs in the L1InfoTreeSync component. When a blockchain reorg occurs and affects L1InfoTree leaves, subscribers can now receive notifications containing details about which GERs were removed. This enables other components (like aggsender) to react to reorgs and update their state accordingly.

🐛 Bug Fixes

None

📋 Config Updates

None

⚠️ Breaking Changes

None - This is a purely additive change. The new SubscribeToGERReorg method adds functionality without modifying existing APIs.

---

Code Review Feedback

🟢 Strengths

1. Excellent test coverage - The PR includes comprehensive tests covering:

   • Basic subscription and event delivery (processor_test.go:392-483)
   • Edge case: no events when no leaves affected (processor_test.go:485-515)
   • Edge case: no events when reorg block doesn't exist (processor_test.go:517-554)
   • Multiple subscribers scenario (processor_test.go:556-609)
   • Integration test via public API (l1infotreesync_test.go:336-375)

2. Well-documented API - The SubscribeToGERReorg method includes clear godoc with usage example (l1infotreesync.go:491-513)

3. Proper encapsulation - The pub/sub mechanism is correctly hidden in the processor, exposed only through the public API

4. Defensive programming - Events are only published when both rowsAffected > 0 AND len(reorgedLeaves) > 0 (processor.go:384-396)

🟡 Suggestions

1. Performance consideration - Line processor.go:345-352: The query fetches ALL affected leaves into memory before the DELETE. For very large reorgs (hundreds or thousands of blocks with multiple events each), this could be memory-intensive. Consider if there's a reasonable upper bound on reorg size, or if pagination/batching would be beneficial.

2. Minor: Log redundancy - Line processor.go:379: The log message includes "block rows affected" and "l1info_leaf entries removed", but the first might be confusing since one block can have multiple l1info_leaf entries. Consider rewording to "blocks removed" for clarity.

3. Consistency - The GERReorgEvent struct at processor.go:126-136 follows good patterns. Consider if Timestamp should be time.Time instead of uint64 for better type safety, though keeping it as uint64 is acceptable for JSON serialization compatibility.

Code Quality Assessment

Go Best Practices: ✅

• Proper error handling throughout
• Follows aggkit naming conventions (aggkitcommon alias)
• Appropriate use of mutex for thread-safety (halted/unhalt)
• Uses testify with require (not assert) as specified in CLAUDE.md

Thread Safety: ✅

• The gerReorgNotifier uses aggkitcommon.PubSub which should handle concurrent subscribers
• The reorg operation properly uses transactions

Error Handling: ✅

• Properly checks sql.ErrNoRows when querying affected leaves
• Transaction rollback is correctly deferred

Test Coverage: ✅

• Tests cover happy path, edge cases, and concurrent scenarios
• Concurrent test (processor_test.go:292-390) is particularly thorough

Security & Performance

Security: ✅ No security concerns identified

• No SQL injection (uses parameterized queries)
• No unauthorized access patterns

Performance: 🟡 Minor consideration

• The query at processor.go:347 could be expensive for large reorgs, but this is likely acceptable given that reorgs are rare events

---

Summary

This is a well-implemented feature that adds important reorg notification capabilities to the l1infotreesync component. The code quality is high, with excellent test coverage and clear documentation. The pub/sub pattern is appropriate for this use case.

Recommendation: ✅ Approve - No blocking issues found. The suggestions above are optional improvements that don't block merging.

---

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
95.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud