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

Raft upgrade compatibility: member rejoining, WAL page sizes and legacy HTTP headers

Đã đóng
  • Có gì không ổn?
#299 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/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ệ
csharp
Lĩnh vực
api, databases, distributed-systems

Hướng nghiên cứu

Start with the focused upstream HTTP cluster test and the existing downstream membership test for the rejoin failure. Then inspect the WAL fixture and test referenced in PR #403, along with MoveToStandbyState, the Leader setter, UnfreezeAsync, and legacy HTTP header handling. Done means regression coverage passes for member rejoining, old and new WAL page sizes, and absent legacy headers while malformed present values remain rejected.

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

Mô tả

Two blockers encountered while validating a 6.6.0 → 6.7.2 Raft upgrade

@sakno

Downstream tracking: https://github.com/SlimPlanet/SlimFaas/issues/402. Tested on macOS ARM64 (.NET SDK 10.0.300, 16 KiB system pages), with three real Raft nodes and with focused tests against develop (f10ace6).

1. A removed live member cannot rejoin

Create a three-node HTTP Raft cluster, remove one live follower, append another entry, and add the follower again. Catch-up applies the removal before the node receives the re-addition. Subsequent AppendEntries returns HTTP 500 / QuorumUnreachableException, and the follower does not apply the re-addition.

MoveToStandbyState(resumable: false) faults the election task. The Leader setter subsequently accesses that completed task's Result without checking success. In addition, UnfreezeAsync short-circuits on the previously completed readiness probe, and the old leadership task remains faulted.

The existing downstream membership test passes on 6.6.0 and fails repeatedly on 6.7.2. A focused upstream HTTP cluster test reproduces the failure without downstream application code.

2. Existing WAL metadata pages are interpreted using a different size

WAL metadata pages created with 6.6.0 have a 4096-byte layout. Newer constructors use max(4096, Environment.SystemPageSize), which is 16384 on this host. After correctly restoring the snapshot, reopening the compacted WAL fails with:

WriteAheadLog.InternalException: WAL page 0 doesn't exist on the disk
  WriteAheadLog.MetadataPageManager.GetView
  WriteAheadLog.ApplyAsync
  WriteAheadLog.InitializeAsync

A rolling upgrade fails at its first follower; all 180 synthetic sets were verified on every node before upgrading. The same saved snapshot/WAL restores successfully with 6.6.0. The fixture and test are in https://github.com/SlimPlanet/SlimFaas/pull/403.

The persisted page size needs to survive reopening, including logs already created with the newer larger-page layout. Invalid/mixed page sizes should fail before files are opened or resized. Private-memory buffers also need an alignment compatible with legacy pages smaller than the OS page size.

A proposed fix and tests are being prepared against develop. No causal link to the original downstream staging incident is claimed.

Additional rolling-upgrade blocker: HTTP headers

After correcting WAL restoration, the next real 6.6.0 → 6.7.2 native rolling-upgrade attempt fails because X-Raft-State-Version is required on incoming requests. Legacy nodes have no state version header (implicit version zero). Conversely, a new leader requires X-Raft-Last-Index on AppendEntries responses, which older followers do not emit. Both absent headers need legacy-compatible defaults while keeping malformed present values rejected. Three regression cases fail before this compatibility fix. Tracked with the other fixes in #300.

Ngôn ngữ chính
C#
Star
2k
Fork
159
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
1

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

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 dotnet/dotNext

Tất cả issue của dotnet/dotNext

Issue tương tự

Thêm issue về C#

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.