Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[CI] NettyClientTest.testServerDisconnection may fail with DisconnectException

Open Beginner friendly
  • Is something wrong?
#4,693 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@yangshangqing95 is already working on this.

Since Oct 17, 2026.

  • #4694 by @yangshangqing95 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
testing

Research direction

Start with NettyClientTest.testServerDisconnection around the failing assertion at line 165. Read how the test waits for the connection map to become empty after the request fails, then add a wait after nettyServer.close() and before the next request while retaining the existing cleanup wait. Run the targeted test repeatedly; it should consistently assert ConnectException.

Written by the indexing model from the issue text.

Description

Search before asking
  • I searched in the issues and found nothing similar.
Fluss version

1.0.0 (latest release)

Please describe the bug 🐞

NettyClientTest.testServerDisconnection can still fail intermittently in CI after #4344.

The test expects a ConnectException when sending a request after shutting down the Netty server, but occasionally receives a DisconnectException instead:

NettyClientTest.testServerDisconnection:165

Expecting actual throwable to be an instance of:
  java.net.ConnectException
but was:
  org.apache.fluss.exception.DisconnectException:
  Cannot send request to server localhost:40463
  (id: cs-1, rack: null) because it is disconnected.

https://github.com/apache/fluss/actions/runs/39053988878/job/117458107688?pr=4545

After nettyServer.close(), the client detects the disconnection and asynchronously removes the old ServerConnection from its connection map.

However, the test immediately sends another request without waiting for the old connection to be removed.

If the request arrives after the connection has entered the DISCONNECTED state but before it is removed from the map, NettyClient.getOrCreateConnection() may return the disconnected connection.

In this case, ServerConnection.doSend() fails the request with a DisconnectException rather than attempting a new connection that would fail with a ConnectException.

This makes the exception assertion sensitive to the timing of asynchronous connection cleanup.

The previous fix in #4344 added a retry to wait for the connection map to become empty, but that retry happens after the failed request and therefore does not prevent this race.

Solution

Wait for the old connection to be removed after shutting down the server and before sending the next request.

Keep the existing retry after the failed request to ensure that the newly created, failed connection is also cleaned up before restarting the server.

This preserves the existing ConnectException assertion and requires no changes to production code.

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Dominant language
Java
Stars
2.2k
Forks
656
Avg merge
2d 2h
Merged PRs (30d)
120

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/fluss

All issues in apache/fluss

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.