Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#299 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
api, databases, distributed-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C#
Stelle
2k
Fork
159
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/dotNext

Tutte le issue di dotnet/dotNext

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.