`CREATE TABLE` / `DROP TABLE` hang on a current-thread tokio runtime and panic outside a runtime

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

Los mantenedores suelen responder en 1 día

@mikamikasuki ya está trabajando en esto.

Desde el 2/10/2026.

  • #45 de @mikamikasuki — abierto

Evaluación

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

Línea de trabajo

Start in crates/datafusion/src/schema.rs at the register_table and deregister_table implementations linked in the issue, then reproduce the behavior with the delayed catalog on a current-thread Tokio runtime and outside any runtime. Trace how the synchronous SchemaProvider methods wait for catalog operations. Done means CREATE TABLE and DROP TABLE complete or return an error on both runtime flavors without panicking outside a runtime.

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

Descripción

bug
Describe the bug

IcebergSchemaProvider::register_table and deregister_table are synchronous SchemaProvider methods that DataFusion calls while executing SQL. They run the catalog call inside tokio::task::spawn_blocking with Handle::current().block_on, then wait for the JoinHandle with futures::executor::block_on on the calling thread (schema.rs#L176-L207, schema.rs#L221-L243).

That blocks the thread that called into DataFusion. On a current-thread runtime, that thread is the only one that drives tokio's I/O and timer drivers. Handle::block_on on the blocking-pool thread doesn't drive them, so a catalog call that awaits network I/O or a timer never completes. That covers REST, Glue, HMS and similar catalogs.

To Reproduce
  1. Wrap a MemoryCatalog in a Catalog implementation whose methods await tokio::time::sleep(Duration::from_millis(2)) before delegating, to stand in for a network catalog.
  2. On a runtime built with tokio::runtime::Builder::new_current_thread().enable_all(), register it through IcebergCatalogProvider and run CREATE TABLE ice.ns.created (id INT NOT NULL).

No result after 10 seconds: the statement hangs.

Calling register_table from a thread with no tokio runtime panics:

thread '<unnamed>' panicked at crates/datafusion/src/schema.rs:177:22:
there is no reactor running, must be called from the context of a Tokio 1.x runtime

On a multi-thread runtime the statement completed in this test, but it keeps the calling thread blocked for the whole catalog round trip.

Expected behavior

CREATE TABLE and DROP TABLE complete or return an error on either runtime flavor. The synchronous methods don't panic when called outside a runtime.

Additional context

#24 (section 3) discusses moving remote create/drop behind an async boundary; this issue is the concrete failure in the current implementation. #[tokio::test] uses a current-thread runtime by default. The existing tests pass only because MemoryCatalog on a local filesystem never needs the I/O or timer driver.

Lenguaje dominante
Rust
Estrellas
30
Forks
30
Merge medio
3 d 19 h
PR fusionados (30 d)
15

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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/datafusion-iceberg

Todos los issues de apache/datafusion-iceberg

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.