Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#436 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@realAaronWu arbeitet bereits daran.

Seit 16.10.2026.

  • #437 von @realAaronWu — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
15/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
cpp
Bereich
backend

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
C++
Sterne
68
Forks
34
Ø Merge
3 T. 18 Std.
Gemergte PRs (30 T.)
44

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/paimon-cpp

Alle Issues in apache/paimon-cpp

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.