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

[BUG][PPL] Handle cancellation during Calcite-to-V2 fallback for sync and async queries

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
backend, databases

Línea de trabajo

Start by tracing the shared QueryService execution path used by synchronous PPL and async PPLQueryRunner, then inspect QueryJob and native PPL task cancellation. Add deterministic concurrency tests for both cancellation-versus-fallback orderings and the listed cancellation scenarios, with fallback enabled. Done means cancellation prevents fallback when it wins admission, admitted fallback stops and cleans up when cancellation follows, and sync/async integration tests verify observable attempts, worker drain, and PIT cleanup.

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

Descripción

untriaged

Problem

Synchronous PPL and async PPL execution share QueryService and its Calcite-to-V2 fallback decision. When cancellation races with an execution failure, the fallback path can treat that failure as an ordinary error and start V2 execution after cancellation was requested.

Recognizing CancellationException, TaskCancelledException, or wrapped/suppressed InterruptedException is only an exception-based safeguard. Cancellation state can be true while the exception contains no cancellation marker. There is also a race between checking a flag and starting fallback.

This issue tracks cancellation/fallback handling separately from the async DELETE work in #5846. It covers both synchronous and asynchronous PPL, rather than relying on async-only QueryJob state. Related: #5765 and production hardening in #5801.

Relevant behavior and evidence

  • Normal synchronous PPL requests and async PPLQueryRunner requests both reach the same QueryService execution path.
  • QueryJob owns async lifecycle status. Synchronous queries have no QueryJob; native PPL task cancellation must also participate.
  • Async DELETE removes the job from the store before cancelling it, so executing queries cannot depend on a later job-store lookup.
  • Unit-level regression scenarios reproduced V2 invocation after interrupted PIT waiting and after cancellation was suppressed during resource cleanup when plugins.calcite.fallback.allowed=true. These are unit-level reproductions, not a claimed end-to-end production incident.
  • Existing async cancellation ITs verify cancellation acknowledgment, worker drain, bounded search activity, and PIT cleanup. They do not directly observe V2 fallback attempts or force the cancellation/fallback race; fallback is disabled by default.

Proposed direction

Use an explicit control allocated per PPL execution/task, shared with the async job when one exists. Keep OpenSearch task types out of the core-facing contract. Publish cancellation before callbacks and before exposing the relevant cancellation state, and atomically coordinate that publication with fallback admission. Propagate the same control across worker handoffs.

The implementation should define two orderings:

  1. Cancellation wins before fallback admission: V2 fallback must not start.
  2. Fallback was admitted first: cancellation must reach that execution, with bounded stop and cleanup behavior. Admission alone does not guarantee that already-running work stops.

Exception recognition may remain a secondary safeguard; it must not be the sole cancellation authority. Preserve timeout failure semantics and ordinary uncancelled fallback behavior. The final design need not use the proposed API shape if another explicit-state solution meets these guarantees.

Acceptance criteria

  • Cover synchronous PPL task cancellation and async PPL DELETE, including owner forwarding.
  • A cancelled execution followed by an ordinary error with no cancellation cause cannot be admitted to V2 fallback.
  • Define and test cancellation-versus-fallback admission ordering with deterministic concurrency tests.
  • Define and verify stopping and cleanup when fallback was admitted before cancellation.
  • Cancellation remains observable after async job removal and across worker/thread handoffs; signals do not leak between queries on reused workers.
  • Preserve terminal-state races, timeout failure semantics, and successful unsupported-query fallback when no cancellation is requested.
  • Add UTs with fallback enabled for plain errors, interrupted PIT waiting, suppressed cleanup cancellation, and both race orderings.
  • Add sync and async ITs with fallback explicitly enabled and restored, and observable fallback attempts. Verify worker drain and PIT/search-context cleanup.

Scope decision for #5846

At the author's request, cancellation/fallback policy changes and their dedicated regression tests are deferred to this issue. Regular async cancellation, deletion, routing, authorization, retention cleanup, and their lifecycle ITs remain in #5846.

Lenguaje dominante
Java
Estrellas
175
Forks
231
Merge medio
2 d 5 h
PR fusionados (30 d)
37

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 opensearch-project/sql

Todos los issues de opensearch-project/sql

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.