[BUG] PPL subsearch maxout settings do not apply on the Analytics Engine path (diverges at defaults)

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
活発
技術スタック
java
領域
api, backend

調査の方向性

まず UnifiedQueryContext.Builder に記載されているデフォルト値と、分類テスト everySeededPlanningSettingIsClassified を読み、その後 RestUnifiedQueryAction.FORWARDED_CLUSTER_SETTINGS と #5611 のコンテキストを調べます。REST リクエストで両方の設定を転送するか、相違点を明示的に文書化するかをメンテナーが選択し、関連するテストとリリースノートに関する決定が記録された時点で、この Issue は完了です。

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

説明

analytic-engine bug design PPL
What is the bug?

On the Analytics Engine (unified query) path, PPL subsearches run unbounded, while the default (non-AE) pipeline caps them. Unlike the other settings-fidelity gaps in this area, this one diverges at defaults — no operator configuration is required to hit it.

Setting Cluster default AE path value
plugins.ppl.subsearch.maxout 10000 0 (unlimited)
plugins.ppl.join.subsearch_maxout 50000 0 (unlimited)

Verified on a default AE context:

SysLimit[querySizeLimit=10000, subsearchLimit=0, joinSubsearchLimit=0]

SysLimit.fromSettings reads both keys, and 0 means "no LogicalSystemLimit injected", so nothing bounds the subsearch.

Root cause — and why this one is a design question, not a plain bug

This is deliberate, and documented in UnifiedQueryContext.Builder:

Settings.Key#PPL_JOIN_SUBSEARCH_MAXOUT defaults to 0 to avoid injecting LogicalSystemLimit into the logical plan, which is an OpenSearch-specific operational concern irrelevant to external consumers of the unified query API. Settings.Key#PPL_SUBSEARCH_MAXOUT is set to 0 for the same reason.

That rationale holds for external consumers of the unified query API as a library (e.g. planning PPL for a non-OpenSearch execution target), where an OpenSearch operational cap is indeed meaningless.

It does not obviously hold for the in-cluster REST path, where the query is being served by an OpenSearch node, consumes that node's memory, and the operator has configured a cap expecting it to apply. Two queries against the same cluster get different memory-safety guarantees purely based on whether the target index happens to use the composite data format.

What is the expected behavior?

Needs a maintainer decision between:

Option A — forward from the REST handler. Add both keys to RestUnifiedQueryAction.FORWARDED_CLUSTER_SETTINGS. This preserves the library default of "unlimited" for external API consumers (who never go through the REST handler) while restoring cluster fidelity in-cluster. Minimal change, and it keeps the documented rationale intact for the case it was written for.

Caveat: this is a behavior change at defaults — AE subsearches would go from unbounded to capped at 10000 / 50000. Queries relying on the current unbounded behavior would start hitting the cap. Needs a release note.

Option B — keep as-is. Accept that AE subsearches are unbounded by design, and document the divergence explicitly so operators know the cap does not apply to composite indices.

Do you have any additional context?

Found while fixing the same class of defect in #5611 (settings the AE path silently ignored). That PR forwards plugins.query.size_limit, plugins.ppl.pattern.*, and plugins.ppl.values.max.limit, and explicitly excludes these two keys pending this decision — the exclusion is pinned by a test (everySeededPlanningSettingIsClassified) so it stays a conscious choice rather than drift.

Related: #5734 (plugins.calcite.all_join_types.allowed guardrail inactive on the AE path).

主要言語
Java
スター
175
フォーク
233
平均マージ
3日 36分
マージ済み PR（30日）
41

環境構築

はじめの一歩

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

opensearch-project/sql のほかの issue

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

似ている issue

Java の issue をもっと見る

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

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