Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#436 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@realAaronWu y travaille déjà.

Depuis le 16/10/2026.

  • #437 par @realAaronWu — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
15/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
cpp
Domaine
backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
C++
Étoiles
68
Forks
34
Merge moyen
3 j 18 h
PR mergées (30 j)
44

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/paimon-cpp

Toutes les issues de apache/paimon-cpp

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.