Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[client] NotLeaderOrFollowerException persists when a stale TabletServer endpoint is reused

Đang mở
#4,256 6 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@BackendArchitectX đang làm issue này rồi.

Từ ngày 9/9/2026.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java

Hướng nghiên cứu

Bắt đầu từ phần xử lý phía client đối với các yêu cầu listOffsets nhận NotLeaderOrFollowerException, sau đó theo dõi cache kết nối server-UID và đường dẫn làm mới metadata của cluster. Tái hiện chuỗi endpoint cũ được mô tả trong issue và xác minh rằng kết nối bị ảnh hưởng cùng metadata định tuyến được vô hiệu hóa, metadata được làm mới, số lần retry bị giới hạn, và host hoặc port đã thay đổi sẽ thay thế kết nối được lưu trong cache.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

0.8.0

Please describe the bug 🐞

During a rolling upgrade, a TabletServer may restart with a new endpoint, while its old endpoint is reused by another TabletServer. A client may then keep a cached connection for the original server ID that actually connects to the other TabletServer.

A request such as listOffsets reaches the wrong server and receives NotLeaderOrFollowerException. The current handling completes the future exceptionally without disconnecting the cached connection or forcing a cluster metadata refresh. Subsequent caller-side retries reuse the same connection, making the failure persistent.

This is related to #2097 and #3389. Unlike the transient leader-change case described in #3389, the stale endpoint remains reachable because it now belongs to another TabletServer, so no NetworkException is raised to invalidate the connection.

Steps to reproduce

The following sequence illustrates how the problem occurs rather than requiring a deterministic IP-reuse setup:

  1. The client caches server A -> endpoint X.
  2. During a rolling upgrade, server A restarts at endpoint Y, and endpoint X is reused by server B.
  3. Before its membership metadata is refreshed, the client creates a connection for server A using endpoint X. The connection is cached under server A's UID, but its actual peer is server B.
  4. A later metadata refresh may update server A -> endpoint Y, but connection lookup still reuses the existing connection cached by server UID.
  5. Requests for buckets led by server A continue to reach server B and receive NotLeaderOrFollowerException.
  6. Because the exception does not invalidate or disconnect the cached connection, subsequent retries keep using the wrong connection.
Solution

On NotLeaderOrFollowerException, invalidate the affected routing metadata, disconnect the cached connection for the selected leader, refresh cluster metadata, and retry with a bounded retry count.

Also consider replacing an existing connection when the host or port changes for the same server UID.

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Ngôn ngữ chính
Java
Star
2.2k
Fork
656
Merge trung bình
1 ngày 21 giờ
Pull request đã merge (30 ngày)
127

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/fluss

Tất cả issue của apache/fluss

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.