apache / apache/fluss

[server] Refactor CoordinatorEventProcessor and split its tests

Open
#4,312 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
2.1k
Forks
625
Avg merge
3d 14h
Merged PRs (30d)
97

Description

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.

### Motivation

`CoordinatorEventProcessor` has accumulated responsibilities for table and partition lifecycle, server membership, replica and ISR transitions, rebalancing, and snapshot commits. Its size makes changes difficult to
review and increases the coupling between unrelated event handlers.

`CoordinatorEventProcessorTest` has grown alongside it and mixes tests for these different responsibilities. Temporary FileLength suppressions have been added for both files and should be removed after this refactoring.

Proposed work:
- Extract cohesive event-handling responsibilities into focused components within fluss-server, keeping CoordinatorEventProcessor responsible fororchestration and dispatch.
- Preserve execution on the Coordinator event thread, event ordering, fencing checks, error propagation, and ZooKeeper state transitions.
- Split CoordinatorEventProcessorTest into focused test classes aligned with the extracted responsibilities, reusing existing test infrastructure.
- Keep public APIs, RPC protocols, and persisted metadata formats unchanged.

### Solution

_No response_

### Anything else?

_No response_

### Willingness to contribute

- [ ] I'm willing to submit a PR!

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading CoordinatorEventProcessor and CoordinatorEventProcessorTest in fluss-server, mapping each event-handling responsibility and its existing tests. Refactor the responsibilities into focused components while retaining orchestration, ordering, fencing, error propagation, and state transitions. Split the test class accordingly, remove the temporary FileLength suppressions, and verify that public APIs, RPC protocols, and persisted metadata formats remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend, distributed-systems, testing
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.