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

オープン
  • 何か問題がありますか？
#5,849 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
java
領域
backend, databases

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

bug calcite PPL

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.

主要言語
Java
スター
175
フォーク
236
平均マージ
2日 19時間
マージ済み PR（30日）
40

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

opensearch-project/sql のほかの issue

opensearch-project/sql の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。