[MEL] - Pt.2 Integration of Message Extraction Across Arbnode Behind Feature Flag#4402
[MEL] - Pt.2 Integration of Message Extraction Across Arbnode Behind Feature Flag#4402
Conversation
❌ 10 Tests Failed:
View the top 3 failed tests by shortest run time
📣 Thoughts on this report? Let Codecov know! | Powered by Codecov |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #4402 +/- ##
==========================================
+ Coverage 32.71% 33.53% +0.81%
==========================================
Files 494 494
Lines 58386 58612 +226
==========================================
+ Hits 19101 19654 +553
+ Misses 35941 35477 -464
- Partials 3344 3481 +137 |
| s.delayedBridge = delayedBridge | ||
| } | ||
|
|
||
| func (s *TransactionStreamer) SetMsgExtractor(msgExtractor *melrunner.MessageExtractor) { |
There was a problem hiding this comment.
Setter injection makes me nervous.
- Why can't we have the TransactionStreamer be correct by construction?
- It "seems" like there is an assumption later in the code that if inboxTracker is not nil, then it will be used. So, if a TransactionStreamer is constructed with an inboxTracker, and then, later
SetMsgExtractoris set, the non-nil inboxTracker would mask the msgExtractor on line 1188. (Maybe this setter should also set the inboxTracker to nil, or error out if it's not nil? - I really hate panics. Isn't there some other way to handle this?
There was a problem hiding this comment.
I just pushed some changes to this. I was able to remove the panics and use error checks to ensure correctness, but it is not possible to make both mel and tx streamer correct by construction because it would require a reordering of dependencies in the arbnode/node.go initialization logic, which feels dangerous to me because of how many functions would need to be reordered. I think the new approach is a decent compromise. What do you think?
|
Amazing feedback and helpful comments @eljobe ! Thank you. I'll take care of this soon |
| s.delayedBridge = delayedBridge | ||
| } | ||
|
|
||
| func (s *TransactionStreamer) SetMsgExtractor(msgExtractor *melrunner.MessageExtractor) { |
- Return ErrDelayedMessageNotYetFinalized instead of (nil, _, nil) when MEL database doesn't have the parent chain block indexed yet, preventing nil message dereference in delayed sequencer - Remove incorrect waitingForFinalizedBlock assignment that stored a message position where a parent chain block number was expected - Add config validation rejecting BatchPoster + MEL enabled together, since MessageExtractor doesn't implement BatchMetadataFetcher - Remove unused msgExtractor param from getBatchPoster - Fix getDelayedSequencer check ordering so non-sequencer nodes without parent chain reader still return gracefully - Fix grammatical error in delayed sequencer error message Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Fix MEL feature flag bugs from PR #4402
This PR integrates MessageExtraction across the Nitro node gated behind the MEL feature flag configuration, allowing us to run a MEL-enabled node safely. Some of the changes are refactoring of certain variables to other packages to support MEL, but most changes are straightforward.
Depends on #4398