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

fix(executor): avoid retaining a callback when lazy worker startup fails

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

Los mantenedores suelen responder en 1 día

@realAaronWu ya está trabajando en esto.

Desde el 16/10/2026.

  • #437 de @realAaronWu — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
15/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
cpp
Área
backend

Línea de trabajo

The fault is in DefaultExecutor::Add in executor.cpp, which enqueues the callback before lazy worker startup. Read that function and the lazy-startup path under the mutex, and note that status.cpp is compiled alongside it in the reproduction. Done means a failed startup leaves no retained callback, and a regression test injects allocation failures and shows later submissions do not run the failed callback. PR #437 already targets this, so review or coordinate there first.

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

Descripción

Problem

DefaultExecutor::Add queues its callback before reserving/starting lazy worker threads. If worker-vector allocation or thread startup throws, Add reports failure but retains that invocation's callback. A later successful submission can execute it. Callers therefore cannot assume that an escaping submission error means their callback was not accepted.

Actual-source reproduction

Base: 242decffdfdefef01dcd0e52e48c9a1e69792479 (main).
Linux x86_64, GCC 15.3, C++17. A standalone executable compiles the unmodified executor.cpp and status.cpp, with submitting-thread-only scalar-new injection. Executor, callables, promises, and futures are prepared before injection. Faults are disarmed before recovery and shutdown.

For a one-worker executor, observe allocations during the actual first Add, then inject each observed ordinal on a fresh executor. Catch bad_alloc, submit a recovery marker, wait for it on that same single-worker FIFO, and join the executor:

ordinal=1 fired=1 caught=1 observed=1 recovered=1 failed_callback_runs=1
ordinal=2 fired=1 caught=1 observed=2 recovered=1 failed_callback_runs=1
allocations=2 retained=2

The program exits 1 for callback retention, not a crash or timeout. This is executor CPU evidence, not a full native planner reproduction or GPU execution.

Proposed narrow fix and acceptance

  • Complete lazy worker startup under the existing mutex before enqueueing the current callback.
  • Preserve empty/stopped behavior and existing successful scheduling.
  • Test real production-object allocation failures, active injection, successful recovery, partial startup, queue growth, and normal subsequent cleanup.
  • Keep callable ownership/capture lifetimes alive through cleanup in the regression itself.
  • Partial worker startup may leave idle workers; this fix need not restore configured capacity, but must not retain the failed invocation and must permit normal recovery/join.

This is a prerequisite ownership contract related to #435. It does not implement or close that feature: query cancellation, task draining, planning budgets, custom executor contracts, and allocation-failure safety of ShutdownNow remain separate.

Lenguaje dominante
C++
Estrellas
68
Forks
34
Merge medio
3 d 18 h
PR fusionados (30 d)
44

Preparar el entorno

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/paimon-cpp

Todos los issues de apache/paimon-cpp

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.