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

[server] Old table cleanup removes recreated table path mapping

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

Los mantenedores suelen responder en 1 día

@luoyuxia ya está trabajando en esto.

Desde el 15/10/2026.

  • #4657 de @luoyuxia — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
65/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
backend, distributed-systems

Línea de trabajo

Start in CoordinatorContext.removeTable, where tableIdByPath.remove(tablePath) runs unconditionally, and compare it with putTablePath, which overwrites the path mapping for a recreated table. Make the reverse-mapping removal conditional on the entry still pointing to the deleted ID, and add a unit test that puts the old ID, puts the new ID for the same path, removes the old ID, then asserts the path still resolves to the new ID. Also check processTableRegistrationChange for the null TableInfo case. Done when the regression test passes and no null dereference remains on that path.

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

Descripción

Search before asking
Fluss version

main (development). The failure symptom was observed on a downstream 0.9-ali-1.0 build; the CoordinatorContext.removeTable behavior described below is also present on current Apache Fluss main.

Please describe the bug 🐞

CoordinatorContext keeps both tablePathById and tableIdByPath. When a table is dropped, its ZooKeeper table node is deleted first, while replica/assignment cleanup completes later. This allows a table with the same path to be created with a new ID before the old ID reaches CoordinatorContext.removeTable.

For a path P, old ID X, and new ID Y, the following state transition loses the new table's reverse mapping:

  1. The old table has tablePathById[X] = P and tableIdByPath[P] = X.
  2. Drop X, then recreate P as Y before the old cleanup completes. putTablePath(Y, P) sets tableIdByPath[P] = Y; tableInfoById[Y] is populated.
  3. The delayed cleanup calls removeTable(X). It removes tablePathById[X], then unconditionally calls tableIdByPath.remove(P), even though that entry now belongs to Y.
  4. getTableIdByPath(P) returns UNKNOWN_TABLE_ID, while getTableInfoById(Y) can still return the new table.

A small CoordinatorContext unit test can reproduce the mapping loss without relying on timing:

context.putTablePath(oldId, path);
context.putTablePath(newId, path);
context.removeTable(oldId);
assertThat(context.getTableIdByPath(path)).isEqualTo(newId); // currently fails

Expected: Completing deletion of X must preserve the mapping P -> Y.

Actual: The mapping is removed. A subsequent table registration change resolves P to UNKNOWN_TABLE_ID; processTableRegistrationChange checks only for null, so it obtains a null oldTableInfo and can throw at oldTableInfo.getSchemaInfo(). The lake tiering manager may still retain Y, because its state is keyed separately by table ID.

We observed repeated TablePropertiesChangeEvent failures when setting table.datalake.enabled=false, with oldTableInfo null, while tiering continued to request the affected table. The historical drop/recreate sequence for that deployment is unavailable, so this production symptom is consistent with, but does not prove, the race above.

Solution

In CoordinatorContext.removeTable, remove the reverse mapping only if it still points to the table being deleted, for example tableIdByPath.remove(tablePath, tableId). Add a regression test for the old-ID/new-ID sequence above. Also handle UNKNOWN_TABLE_ID (and a missing TableInfo) in processTableRegistrationChange with a diagnostic log instead of a NullPointerException; that guard alone would not preserve the mapping.

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Lenguaje dominante
Java
Estrellas
2.2k
Forks
646
Merge medio
2 d 28 min
PR fusionados (30 d)
128

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.