Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Consensus Matching Engine: engine.Unit -> ComponentManager #6916

Merged

Conversation

tim-barry
Copy link
Contributor

@tim-barry tim-barry commented Jan 17, 2025

Refactor the Consensus Matching Engine to move away from deprecated interfaces, as well as improve error handling and documentation. The changes are relatively straightforward drop-in replacements, due to the engine already being structured as an initial set of workers launched when the engine is started.

  • Replace deprecated engine.Unit with ComponentManager
  • Replace deprecated network.Engine with network.MessageProcessor
  • Use concrete types where appropriate
  • Use ctx.Throw to propagate irrecoverable errors instead of Log.Fatal, which also allows for tests to verify behaviour by using mock contexts

Closes #6854

…Processor

Remove `Submit`, `SubmitLocal`, `ProcessLocal` that implemented network.Engine,
clean up error checking, and update doc comments
@codecov-commenter
Copy link

codecov-commenter commented Jan 17, 2025

Codecov Report

Attention: Patch coverage is 74.28571% with 9 lines in your changes missing coverage. Please review.

Project coverage is 41.10%. Comparing base (8c170e3) to head (85e2881).
Report is 79 commits behind head on master.

Files with missing lines Patch % Lines
engine/consensus/matching/engine.go 74.28% 9 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #6916   +/-   ##
=======================================
  Coverage   41.09%   41.10%           
=======================================
  Files        2121     2119    -2     
  Lines      185912   185867   -45     
=======================================
  Hits        76395    76395           
+ Misses     103104   103066   -38     
+ Partials     6413     6406    -7     
Flag Coverage Δ
unittests 41.10% <74.28%> (+<0.01%) ⬆️

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.

e.log.Fatal().Err(err).Msg("internal error processing event from requester module")
r, ok := receipt.(*flow.ExecutionReceipt)
if !ok {
e.log.Fatal().Err(engine.IncompatibleInputTypeError).Msg("internal error processing event from requester module")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that ideally HandleReceipt would also be able to use ctx.Throw instead of Log.Fatal, but the function type is already dictated by being used as a HandleFunc by the Requester engine. Could be pushed to a future refactor of Requester Engine (since that one also still uses engine.Unit).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this could be done as part of updating the requester engine. It would be great to have type-safe handler functions in the requester engine, which we could implement by making the requester engine and its Create/Handle functions generic.

@tim-barry tim-barry marked this pull request as ready for review January 20, 2025 17:03
@tim-barry tim-barry requested a review from a team as a code owner January 20, 2025 17:03
e.log.Fatal().Err(err).Msg("internal error processing event from requester module")
r, ok := receipt.(*flow.ExecutionReceipt)
if !ok {
e.log.Fatal().Err(engine.IncompatibleInputTypeError).Msg("internal error processing event from requester module")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this could be done as part of updating the requester engine. It would be great to have type-safe handler functions in the requester engine, which we could implement by making the requester engine and its Create/Handle functions generic.

engine/consensus/matching/engine_test.go Outdated Show resolved Hide resolved
engine/consensus/matching/engine_test.go Outdated Show resolved Hide resolved
Copy link
Member

@AlexHentschel AlexHentschel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work.

engine/consensus/matching/engine.go Outdated Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is an important best practise to register the component with the networking layer (👉 this code) only at the very end of the constructor, after we have fully constructed the component (including all the worker routines 👉 this code).

I like to frame this as a very foundational best practise in software engineering: don't reveal a reference to a component until the component is fully constructed. Usually, we implement this via a constructor that only at the end returns the reference to the constructed object. Our business logic is a bit more complicated, in that we don't want to rely on the caller to registers the matching.Engine with the networking layer - so we do it within the constructor; however then we have to make sure we are not revealing the pointer of the object under construction until the object instantiation is properly completed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense - I wasn't thinking deliberately enough about network interfaces, and was assuming the ComponentManager would want to be last due to the workers it starts potentially needing to access parts of the engine under construction for a similar reason; but basically forgot that the worker routines will only actually need those resources once the component is Started (after construction).

engine/consensus/matching/engine.go Outdated Show resolved Hide resolved
engine/consensus/matching/engine.go Outdated Show resolved Hide resolved
tim-barry and others added 2 commits January 23, 2025 11:52
Remove separate ComponentManager pointer since only the Component interface is used

Co-authored-by: Alexander Hentschel <[email protected]>
Ensure the engine can only be accessed externally once construction is complete.
See #6916 (comment)
@tim-barry tim-barry added this pull request to the merge queue Jan 23, 2025
Merged via the queue into master with commit 055ac99 Jan 23, 2025
56 checks passed
@tim-barry tim-barry deleted the tim/6854-consensus-matching-engine-componentmanager-refactor branch January 23, 2025 22:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor Consensus Matching Engine: engine.Unit -> ComponentManager
4 participants