Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[server] Periodic KV snapshot initialization races with Replica deletion

Abierto
  • ¿Algo no está bien?
#4,599 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@MaheshS08 ya está trabajando en esto.

Desde el 13/10/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
53/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
backend, databases

Línea de trabajo

Start with Replica.delete() and Replica.dropKv(), then trace how closeableRegistryForKv closes PeriodicSnapshotManager and how snapshot initialization runs under kvLock. Use the deterministic regression described in the issue with the existing ReplicaTest fixtures to reproduce the registry-closing window. Done means deletion stops or synchronizes periodic snapshot initialization before the KV registry closes, with the regression confirming no closed-registry IOException is logged.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

main (development)

Please describe the bug 🐞

Periodic KV snapshot initialization can race with Replica deletion and attempt to register resources after the Replica's KV registry has been closed.

java.io.IOException: Cannot register Closeable, registry is already closed. Closing argument.
    at AbstractAutoCloseableRegistry.registerCloseable
    at AsyncSnapshotCallable$AsyncSnapshotTask.<init>
    at AsyncSnapshotCallable.toAsyncSnapshotFutureTask
    at SnapshotRunner.snapshot
    at KvTabletSnapshotTarget.initSnapshot
    at PeriodicSnapshotManager.lambda$triggerSnapshot$2

Replica.dropKv() closes closeableRegistryForKv. The registry first sets closed=true, then closes its registered resources, including PeriodicSnapshotManager. A scheduled snapshot can still run between these steps and reach task registration while the registry is already closed.

The manager's close() also does not serialize with snapshot initialization under the tablet's kvLock, so cancelling the scheduled future alone does not cover an initialization already in progress.

Deterministic reproduction

A local regression uses the existing ReplicaTest fixtures and real Replica, RocksDB, snapshot target, runner and registry:

  1. Create a KV leader, write and flush records, and retain the snapshot timer automatically scheduled during leader initialization.
  2. Register a latch-controlled Closeable after the snapshot manager. Call Replica.delete() on another thread and pause resource closing after the registry becomes closed, before the manager stops.
  3. Execute the original scheduled timer, then release the latch and wait for deletion to finish.

This enlarges a valid closing window without mocking the initialization exception. The assertion that no closed-registry IOException is logged fails on both revisions:

Regression Base b530fcc2 PR #4492 19870c605
Retry after snapshot-init failure Fails: no replacement task Passes
Snapshot initialization during Replica deletion Fails: closed-registry IOException Fails: same IOException

Four occurrences were observed during test table deletion. Deletion completed, and no snapshot corruption was established.

Expected behavior

Replica deletion should stop or cancel periodic snapshots cleanly, without allowing snapshot task registration after the KV registry closes.

Solution

Serialize stopping the snapshot manager with snapshot initialization before closing the KV registry and dropping the tablet, while preserving cancellation and cleanup of already registered tasks.

Related: #4489 and #4492 address retry after initialization failure. The closing race exists before that PR and requires a separate lifecycle fix.

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Lenguaje dominante
Java
Estrellas
2.2k
Forks
656
Merge medio
2 d 14 h
PR fusionados (30 d)
108

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/fluss

Todos los issues de apache/fluss

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.