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

[BUG] KVRangeRestorer leaves the restore future uncompleted when startRestore() throws, permanently wedging the range

Aperta Adatta ai principianti
  • Qualcosa non va?
#303 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@ImDanXie ci sta già lavorando.

Dal 25/9/2026.

  • #310 di @ImDanXie — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
88/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend, distributed-systems, testing-qa

Direzione di ricerca

Inizia in base-kv/base-kv-store-server/src/main/java/org/apache/bifromq/basekv/store/range/KVRangeRestorer.java, in restoreFrom(), quindi segui i percorsi di errore di startRestore() e messenger.send(). Aggiungi il test di regressione descritto nell’issue: verifica che un errore sincrono di avvio completi il future in modo eccezionale e che ritentare con lo stesso snapshot avvii una nuova sessione.

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

Descrizione

Environment
  • BiFroMQ 4.0.0 / main @ eef5e3af
  • Module: base-kv/base-kv-store-server
  • File: base-kv/base-kv-store-server/src/main/java/org/apache/bifromq/basekv/store/range/KVRangeRestorer.java (restoreFrom)
Summary

restoreFrom() wraps snapshot-install setup in try { ... } catch (Throwable t) { log.error(...) } and returns the session's doneFuture. If startRestore() (or the subsequent messenger.send()) throws synchronously, the future is never completed — and there is no timeout on this path (unlike the receiver-driven path, which has an idle timeout). Worse, the session stays cached in currentSession: a retry with the same snapshot from the same leader hits the reuse branch and returns the same dead future, so the range is permanently stuck — it never applies anything and never retries.

Snapshot install is mandatory on expansion/rebalance, so any transient synchronous failure here is a hard wedge.

Suggested fix

Complete the future exceptionally in the catch block; the caller observes the failure and a retry starts a fresh session:

} catch (Throwable t) {
    log.error("Unexpected error", t);
    onDone.completeExceptionally(new KVRangeStoreException("Snapshot restore failed to start", t));
}
Test

New regression test: startRestore throws → the future must be completed exceptionally, and a retry with the same snapshot must start a fresh session (not reuse the dead one). Fails on the unfixed code.

Production validation

A 6-node BifroMQ 4.0.0 cluster (standalone.sh, systemd, mTLS clientAuth=REQUIRE), fronted by a TCP load balancer with 6 backends. Live clients: 3 bridge replicas (MQTT5, $oshare subscribers) and 10 backend service instances (persistent sessions). RocksDB engine, default configuration otherwise.

The fix (plus other changes) was rolled across all six nodes one node at a time (wholesale lib/ replacement, then restart), with a per-node gate (service active, all four ports listening, cluster mesh re-established). Six of six nodes succeeded, zero rollbacks.

Post-deploy checks (all measured after the rollout):

Check Result
Cluster mesh (inter-node 8898/8899 connections, per node) 408–417 established on every node
Live client connections (3 bridge replicas + 10 backend services over mTLS) 13/13 reconnected and stable
Cross-node delivery end-to-end publish on one node → bridge (connected elsewhere) consumed it → forwarded (counter 0 → 1)
Client-visible protocol smoke connect / subscribe / publish with QoS 1 all CONNACK 0 / PUBACK 0

No wedged range (a range stuck in snapshot restore) was observed before or after the deployment; the fix closes the permanent-wedge path should a synchronous start failure ever occur.

Lingua principale
Java
Stelle
805
Fork
99
Merge medio
16h 32m
PR unite (30g)
2

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

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 apache/bifromq

Tutte le issue di apache/bifromq

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.