Add include_metadata request parameter for PPL queries #5235 by ishag4 · Pull Request #5412 · opensearch-project/sql

ishag4 · 2026-05-06T19:40:17Z

Description

Add a request-level parameter include_metadata to the PPL query API:

POST /_plugins/_ppl?include_metadata=true
{
"query": "source=logs | where level='ERROR' | fields * | head 10"
}
Result: All regular fields PLUS metadata fields (_id, _index, _score, etc.)

Related Issues

Resolves #5235

Check List

New functionality includes testing.
New functionality has been documented.
New functionality has javadoc added.
New functionality has a user manual doc added.
New PPL command checklist all confirmed.
API changes companion pull request created.
Commits are signed per the DCO using --signoff or -s.
Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

…ject#5235 Signed-off-by: Isha Gupta <igupta24@apple.com>

github-actions · 2026-05-06T19:42:13Z

PR Reviewer Guide 🔍

(Review updated until commit `9c67c76`)

Here are some key observations to aid the review process:

🧪 PR contains tests
🔒 No security concerns identified
✅ No TODO sections
🔀 No multiple PR themes
⚡ Recommended focus areas for review Possible Issue The new visitAllFieldsExcludeMeta method delegates to visitAllFields, but the comment says "visitors that don't would otherwise silently return null here and NPE in their caller." This suggests the old code returned null. However, the old hunk shows it called visitChildren(node, context), not returning null. If visitChildren is the correct fallback for visitors that don't override this method, then delegating to visitAllFields may break those visitors by changing their traversal behavior. The comment and implementation may be inconsistent with the actual old behavior. public T visitAllFieldsExcludeMeta(AllFieldsExcludeMeta node, C context) { // AllFieldsExcludeMeta is an AllFields, so fall back to visitAllFields by default. Visitors // that need to tell the two apart override this method; visitors that don't would otherwise // silently return null here and NPE in their caller. return visitAllFields(node, context); } Possible Issue The new execute overload at line 115 adds an includeMetadata parameter but does not update the call at line 125 in the legacy path. The comment says "The V2 engine has no notion of metadata fields, so includeMetadata is ignored there," but the method signature at line 125 still calls executeWithLegacy with only four arguments, not five. If executeWithLegacy was updated to accept includeMetadata, this call is missing it. If it was not updated, the comment is misleading because the parameter is not passed at all, not "ignored." public void execute( UnresolvedPlan plan, QueryType queryType, HighlightConfig highlightConfig, boolean includeMetadata, ResponseListener<ExecutionEngine.QueryResponse> listener) { if (shouldUseCalcite(queryType)) { executeWithCalcite(plan, queryType, highlightConfig, includeMetadata, listener); } else { // The V2 engine has no notion of metadata fields, so includeMetadata is ignored there. executeWithLegacy(plan, queryType, listener, Optional.empty()); } } Possible Issue The constructor at line 59 is marked as "Constructor with highlight config and include metadata flag," but it delegates to another constructor at line 56 that is only documented as "Constructor with highlight config." If the constructor at line 49 was not updated to accept includeMetadata, this delegation will fail at runtime with a method-not-found error. The diff does not show the constructor at line 49 being updated to accept the new parameter. /** Constructor with highlight config and include metadata flag. */ public QueryPlan( QueryId queryId, QueryType queryType, UnresolvedPlan plan, QueryService queryService, ResponseListener<ExecutionEngine.QueryResponse> listener, HighlightConfig highlightConfig, boolean includeMetadata) { super(queryId, queryType); this.plan = plan; this.queryService = queryService; this.listener = listener; this.pageSize = Optional.empty(); this.highlightConfig = highlightConfig; this.includeMetadata = includeMetadata; }

github-actions · 2026-05-06T19:42:46Z

PR Code Suggestions ✨

Latest suggestions up to 9c67c76

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Verify lambda metadata inheritance behavior The `includeMetadata` field is copied from parent context during lambda context creation, but it's unclear if this is the intended behavior for lambda scopes. Verify that lambda expressions should inherit the metadata inclusion setting from their parent scope, as this could lead to unexpected metadata field visibility in nested lambda operations. core/src/main/java/org/opensearch/sql/calcite/CalcitePlanContext.java [154] -this.includeMetadata = parent.includeMetadata; // Preserve parent's metadata setting +// Lambda contexts inherit metadata setting from parent scope +// This ensures consistent metadata field visibility across lambda boundaries +this.includeMetadata = parent.includeMetadata; Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that `includeMetadata` is copied from the parent context during lambda context creation. Adding a clarifying comment is helpful for maintainability, though the existing inline comment already explains this. The suggestion to verify the behavior is reasonable but doesn't identify an actual bug.	Low
	Log warning for unsupported parameter The `includeMetadata` parameter is silently ignored for the V2 engine without any validation or warning. Consider logging a warning when `includeMetadata=true` is used with V2 engine to inform users that the parameter has no effect, preventing confusion about why metadata fields are not returned. core/src/main/java/org/opensearch/sql/executor/QueryService.java [123-126] } else { // The V2 engine has no notion of metadata fields, so includeMetadata is ignored there. + if (includeMetadata) { + log.warn("include_metadata parameter is not supported by V2 engine and will be ignored"); + } executeWithLegacy(plan, queryType, listener, Optional.empty()); } Suggestion importance[1-10]: 5 __ Why: The suggestion to log a warning when `includeMetadata=true` is used with the V2 engine could improve user experience by making the ignored parameter more visible. However, the PR already documents this behavior in comments and integration tests, and the parameter is intentionally accepted and ignored rather than rejected. The impact is moderate.	Low
	Clarify null handling for configuration The method returns `false` when `jsonContent` is null, but this could mask configuration errors. Consider whether a null `jsonContent` should be treated differently (e.g., throw an exception) to distinguish between "explicitly set to false" and "configuration missing", ensuring proper error handling for malformed requests. ppl/src/main/java/org/opensearch/sql/ppl/domain/PPLQueryRequest.java [135-140] public boolean getIncludeMetadata() { if (jsonContent == null) { + // Return default when no JSON content provided (e.g., URL-only requests) return false; } return jsonContent.optBoolean(INCLUDE_METADATA_FIELD, false); } Suggestion importance[1-10]: 3 __ Why: The suggestion asks to verify whether `null` `jsonContent` should be handled differently, but the `improved_code` is nearly identical to the `existing_code` (only adds a comment). The current behavior of returning `false` for `null` `jsonContent` is appropriate for URL-only requests, as documented in the new comment. This is a minor documentation improvement rather than a functional change.	Low

Previous suggestions

Suggestions up to commit 282b487

Category	Suggestion	Impact
General	Warn when metadata parameter is ignored The `includeMetadata` parameter is silently ignored for the V2 engine without any validation or warning. If a user explicitly sets `include_metadata=true` but the query uses the V2 engine, they won't receive any indication that their request is being ignored. Consider logging a warning or validating this scenario. core/src/main/java/org/opensearch/sql/executor/QueryService.java [123-126] } else { // The V2 engine has no notion of metadata fields, so includeMetadata is ignored there. + if (includeMetadata) { + log.warn("include_metadata parameter is not supported by the V2 engine and will be ignored"); + } executeWithLegacy(plan, queryType, listener, Optional.empty()); } Suggestion importance[1-10]: 5 __ Why: This is a reasonable usability improvement that would help users understand when their `include_metadata` parameter is being ignored by the V2 engine. The suggestion correctly identifies that silent ignoring could be confusing, and adding a warning would improve the user experience. However, it's not critical functionality.	Low
	Review metadata inheritance in lambda contexts The `includeMetadata` flag is copied from parent context in lambda contexts, but this may not be the intended behavior. Lambda expressions typically operate on already-projected data and shouldn't independently control metadata inclusion. Consider whether lambda contexts should inherit this setting or if it should be reset to a default value. core/src/main/java/org/opensearch/sql/calcite/CalcitePlanContext.java [154] -this.includeMetadata = parent.includeMetadata; // Preserve parent's metadata setting +// Lambda contexts inherit metadata setting from parent for consistency +this.includeMetadata = parent.includeMetadata; Suggestion importance[1-10]: 3 __ Why: The suggestion raises a valid design consideration about whether lambda contexts should inherit `includeMetadata` from their parent. However, the improved code is essentially identical to the existing code (just adds a comment), and the concern is speculative without evidence of actual issues. The inheritance behavior appears intentional based on the comment already present.	Low
	Clarify null handling in metadata getter The method returns `false` when `jsonContent` is null, but this could mask configuration errors. If the request is malformed or missing required content, returning a default value silently may lead to unexpected behavior. Consider whether this null check is appropriate or if it should throw an exception for invalid requests. ppl/src/main/java/org/opensearch/sql/ppl/domain/PPLQueryRequest.java [135-140] public boolean getIncludeMetadata() { if (jsonContent == null) { + // Return default when no JSON content is provided (e.g., GET requests) return false; } return jsonContent.optBoolean(INCLUDE_METADATA_FIELD, false); } Suggestion importance[1-10]: 2 __ Why: The improved code only adds a comment to explain existing behavior, which doesn't change functionality. The null check appears appropriate for handling cases where no JSON content is provided (like GET requests), and the suggestion doesn't identify an actual bug or significant improvement opportunity.	Low

Suggestions up to commit b718cb6

Category	Suggestion	Impact
General	Handle nested field removal consistently The logic for `AllFieldsExcludeMeta` skips nested field removal, which may cause inconsistent behavior. When `include_metadata=false`, nested fields should still be removed to maintain consistency with the default behavior. Consider calling `tryToRemoveNestedFields(context)` for both branches when `!context.isProjectVisited()`. core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [533-545] if (allFields instanceof AllFieldsExcludeMeta) { - // For AllFieldsExcludeMeta (include_metadata=false), should not remove nested fields + // For AllFieldsExcludeMeta (include_metadata=false), remove nested fields if not visited + if (!context.isProjectVisited()) { + tryToRemoveNestedFields(context); + } tryToRemoveMetaFields(context, true); // Force exclude metadata fields } else { // For AllFields (include_metadata=true), include metadata fields if (!context.isProjectVisited()) { tryToRemoveNestedFields(context); } // Mark as project visited to prevent automatic metadata field removal context.setProjectVisited(true); // Don't force exclude metadata fields - let them remain tryToRemoveMetaFields(context, false); } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential inconsistency where `AllFieldsExcludeMeta` skips nested field removal. Adding `tryToRemoveNestedFields(context)` for `AllFieldsExcludeMeta` when `!context.isProjectVisited()` would ensure consistent behavior across both branches and maintain the expected default behavior.	Medium
General	Extract default metadata flag constant The default value for `includeMetadata` is hardcoded as `false` in this overload. If the default behavior changes in the future, this could lead to inconsistencies. Consider extracting the default value to a constant to ensure consistency across the codebase. core/src/main/java/org/opensearch/sql/executor/QueryService.java [106-112] +private static final boolean DEFAULT_INCLUDE_METADATA = false; + public void execute( UnresolvedPlan plan, QueryType queryType, HighlightConfig highlightConfig, ResponseListener<ExecutionEngine.QueryResponse> listener) { - execute(plan, queryType, highlightConfig, false, listener); + execute(plan, queryType, highlightConfig, DEFAULT_INCLUDE_METADATA, listener); } Suggestion importance[1-10]: 5 __ Why: The suggestion improves maintainability by extracting the hardcoded `false` default value into a named constant. This makes the default behavior more explicit and easier to change consistently across the codebase if needed in the future.	Low

Suggestions up to commit 7194590

Category	Suggestion	Impact
General	Remove redundant metadata filtering call The logic for handling `AllFields` (include_metadata=true) calls `tryToRemoveMetaFields(context, false)` which may still remove metadata fields if `!context.isProjectVisited()` evaluates to true. Since `setProjectVisited(true)` is called just before, this creates a timing dependency. Consider removing the `tryToRemoveMetaFields` call entirely for the `AllFields` case to ensure metadata fields are never removed. core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [497-509] if (allFields instanceof AllFieldsExcludeMeta) { // For AllFieldsExcludeMeta (include_metadata=false), remove nested fields and force exclude // metadata tryToRemoveNestedFields(context); tryToRemoveMetaFields(context, true); // Force exclude metadata fields } else { // For AllFields (include_metadata=true), include metadata fields tryToRemoveNestedFields(context); // Mark as project visited to prevent automatic metadata field removal context.setProjectVisited(true); - // Don't force exclude metadata fields - let them remain - tryToRemoveMetaFields(context, false); + // Don't call tryToRemoveMetaFields at all - metadata fields should remain } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential redundancy where `tryToRemoveMetaFields(context, false)` is called after `setProjectVisited(true)`. However, examining the implementation shows this call may still serve a purpose for consistency. The suggestion is valid but represents a minor optimization rather than a critical fix.	Medium
	Warn about metadata parameter loss When falling back to the legacy engine, the `includeMetadata` parameter is not passed through to `executeWithLegacy`. This means that if a user explicitly requested `include_metadata=true` and the query falls back to the legacy engine, their preference will be silently ignored. Consider logging a warning about this limitation or passing the parameter if the legacy engine supports it. core/src/main/java/org/opensearch/sql/executor/QueryService.java [216-222] } catch (Throwable t) { if (isCalciteFallbackAllowed(t) && !(t instanceof NonFallbackCalciteException)) { - log.warn("Fallback to V2 query engine since got exception", t); + log.warn("Fallback to V2 query engine since got exception. Note: include_metadata parameter may not be fully supported in legacy engine.", t); // Legacy engine provides basic metadata support, so fallback is acceptable executeWithLegacy(plan, queryType, listener, Optional.of(t)); } else { propagateCalciteError(t, listener); } Suggestion importance[1-10]: 6 __ Why: Valid observation that `includeMetadata` is not passed to the legacy engine fallback. The suggestion to add a warning is reasonable for user transparency. However, the existing comment already mentions that "Legacy engine provides basic metadata support," so the impact is moderate.	Low
	Clarify force-exclude metadata behavior The condition `context.isIncludeMetadata() && !excludeByForce` creates a logical issue: when `excludeByForce=true`, metadata fields will be removed even if `includeMetadata=true`. This contradicts the user's explicit request to include metadata. Consider whether `excludeByForce` should truly override the user's `includeMetadata` preference, or if this represents a bug in subquery/join scenarios. core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [656-662] private static void tryToRemoveMetaFields(CalcitePlanContext context, boolean excludeByForce) { - // If include_metadata=true, never remove metadata fields + // If include_metadata=true and not forced by subquery/join context, preserve metadata fields if (context.isIncludeMetadata() && !excludeByForce) { return; } + // Note: excludeByForce=true (from joins/subqueries) will override user's includeMetadata preference + // This may need review if metadata should be preserved in those contexts if (excludeByForce \|\| !context.isProjectVisited()) { Suggestion importance[1-10]: 5 __ Why: The suggestion raises a valid design question about whether `excludeByForce` should override `includeMetadata`. However, the current behavior appears intentional for subquery/join contexts where metadata exclusion is necessary. The suggestion adds clarifying comments but doesn't identify a clear bug, making it more of a documentation improvement.	Low

Suggestions up to commit 4f001a6

Category	Suggestion	Impact
General	Remove redundant metadata field filtering call The logic for handling `AllFields` (include_metadata=true) calls `tryToRemoveMetaFields(context, false)` which may still remove metadata fields if `!context.isProjectVisited()` evaluates to true. Since `setProjectVisited(true)` is called just before, this creates a timing dependency. Consider removing the `tryToRemoveMetaFields` call entirely for the `AllFields` case to ensure metadata fields are never removed. core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [497-509] if (allFields instanceof AllFieldsExcludeMeta) { // For AllFieldsExcludeMeta (include_metadata=false), remove nested fields and force exclude // metadata tryToRemoveNestedFields(context); tryToRemoveMetaFields(context, true); // Force exclude metadata fields } else { // For AllFields (include_metadata=true), include metadata fields tryToRemoveNestedFields(context); // Mark as project visited to prevent automatic metadata field removal context.setProjectVisited(true); - // Don't force exclude metadata fields - let them remain - tryToRemoveMetaFields(context, false); + // Don't call tryToRemoveMetaFields at all - metadata fields should remain } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a potential redundancy where `tryToRemoveMetaFields(context, false)` is called after `setProjectVisited(true)`. However, examining the `tryToRemoveMetaFields` implementation shows it checks `context.isIncludeMetadata()` first (lines 658-660), which provides the primary guard. The `setProjectVisited(true)` call serves as a secondary safeguard. While removing the call could simplify the logic, the current implementation is defensive and not incorrect.	Medium
	Preserve metadata flag during engine fallback When falling back to the legacy engine after a Calcite failure, the `includeMetadata` flag is lost and not passed to `executeWithLegacy`. This means users who explicitly requested `include_metadata=true` will silently get different behavior after fallback. Consider preserving the flag or logging a warning about the behavior change. core/src/main/java/org/opensearch/sql/executor/QueryService.java [216-223] } catch (Throwable t) { if (isCalciteFallbackAllowed(t) && !(t instanceof NonFallbackCalciteException)) { - log.warn("Fallback to V2 query engine since got exception", t); + if (includeMetadata) { + log.warn("Fallback to V2 query engine - include_metadata parameter will be ignored", t); + } else { + log.warn("Fallback to V2 query engine since got exception", t); + } // Legacy engine provides basic metadata support, so fallback is acceptable executeWithLegacy(plan, queryType, listener, Optional.of(t)); } else { propagateCalciteError(t, listener); } } Suggestion importance[1-10]: 7 __ Why: This is a valid concern about losing the `includeMetadata` flag during fallback to the legacy engine. Adding a conditional warning when `includeMetadata=true` would help users understand the behavior change. The suggestion improves observability and user experience when fallback occurs, though the impact is limited to fallback scenarios.	Medium
	Warn when unsupported parameter is ignored The `includeMetadata` parameter is silently ignored when using the legacy engine, which could lead to unexpected behavior for users. Consider logging a warning when `includeMetadata=true` is specified but the legacy engine is used, or document this limitation clearly to avoid confusion. core/src/main/java/org/opensearch/sql/executor/QueryService.java [116-121] } else { + if (includeMetadata) { + log.warn("include_metadata parameter is not supported by legacy engine and will be ignored"); + } // Legacy engine always includes basic metadata (schema information) // The includeMetadata flag doesn't affect legacy engine behavior since // it already provides column names, types, and aliases in the schema executeWithLegacy(plan, queryType, listener, Optional.empty()); } Suggestion importance[1-10]: 6 __ Why: Adding a warning when `includeMetadata=true` is used with the legacy engine would improve user experience by making the limitation explicit. However, the comments already document this behavior, and the legacy engine is likely being phased out. The suggestion is valid but has moderate impact since users can discover this through documentation.	Low

Suggestions up to commit c007980

Category	Suggestion	Impact
General	Remove redundant metadata removal call The logic for handling `AllFields` (include_metadata=true) calls `tryToRemoveMetaFields(context, false)` which may still remove metadata fields if `!context.isProjectVisited()` evaluates to true. Since `setProjectVisited(true)` is called just before, this creates a timing dependency. Consider removing the `tryToRemoveMetaFields` call entirely for the `AllFields` case to ensure metadata fields are never removed. core/src/main/java/org/opensearch/sql/calcite/CalciteRelNodeVisitor.java [497-509] if (allFields instanceof AllFieldsExcludeMeta) { // For AllFieldsExcludeMeta (include_metadata=false), remove nested fields and force exclude // metadata tryToRemoveNestedFields(context); tryToRemoveMetaFields(context, true); // Force exclude metadata fields } else { // For AllFields (include_metadata=true), include metadata fields tryToRemoveNestedFields(context); // Mark as project visited to prevent automatic metadata field removal context.setProjectVisited(true); - // Don't force exclude metadata fields - let them remain - tryToRemoveMetaFields(context, false); + // Don't call tryToRemoveMetaFields at all - metadata fields should remain } Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that calling `tryToRemoveMetaFields(context, false)` after `setProjectVisited(true)` creates a timing dependency. However, examining the `tryToRemoveMetaFields` implementation shows it checks `context.isIncludeMetadata()` first (lines 658-660), which provides the primary protection. Removing the call would simplify the logic and eliminate the timing dependency, making the code more maintainable.	Medium
	Preserve parameter during fallback When falling back to the legacy engine after a Calcite failure, the `includeMetadata` parameter is lost and not passed to `executeWithLegacy`. This means users who specified `include_metadata=true` will silently get different behavior after fallback. Consider preserving the parameter or logging a warning about the behavior change. core/src/main/java/org/opensearch/sql/executor/QueryService.java [216-223] } catch (Throwable t) { if (isCalciteFallbackAllowed(t) && !(t instanceof NonFallbackCalciteException)) { log.warn("Fallback to V2 query engine since got exception", t); + if (includeMetadata) { + log.warn("include_metadata parameter will be ignored in legacy engine fallback"); + } // Legacy engine provides basic metadata support, so fallback is acceptable executeWithLegacy(plan, queryType, listener, Optional.of(t)); } else { propagateCalciteError(t, listener); } } Suggestion importance[1-10]: 6 __ Why: The suggestion identifies a valid concern about the `includeMetadata` parameter being lost during fallback to the legacy engine. Adding a warning would help users understand the behavior change. However, since the legacy engine doesn't support this parameter by design (as documented in the code), this is more of a user communication improvement than a functional bug.	Low
	Warn when parameter is ignored The `includeMetadata` parameter is silently ignored when using the legacy engine, which could lead to unexpected behavior for users. Consider logging a warning when `includeMetadata=true` is specified but the legacy engine is used, or document this limitation clearly in the method signature. core/src/main/java/org/opensearch/sql/executor/QueryService.java [116-121] } else { + if (includeMetadata) { + log.warn("include_metadata parameter is not supported by legacy engine and will be ignored"); + } // Legacy engine always includes basic metadata (schema information) // The includeMetadata flag doesn't affect legacy engine behavior since // it already provides column names, types, and aliases in the schema executeWithLegacy(plan, queryType, listener, Optional.empty()); } Suggestion importance[1-10]: 5 __ Why: Adding a warning when `includeMetadata=true` is used with the legacy engine would improve user experience by making the limitation explicit. However, the existing comment already documents this behavior, and the parameter is intentionally designed to only affect the Calcite engine. The suggestion is valid but represents a minor enhancement rather than a critical issue.	Low

ishag4 · 2026-05-08T07:46:24Z

Hi @LantaoJin @penghuo @RyanL1997 @Swiddis Could you please review?

LantaoJin

Please add integration tests for this enhancement and update documentation (add a new section in endpoint.md

Signed-off-by: Isha Gupta <igupta24@apple.com>

github-actions · 2026-05-17T07:50:44Z

Persistent review updated to latest commit b79855b

ishag4 · 2026-05-17T19:00:17Z

Hi @LantaoJin @penghuo @RyanL1997 @Swiddis Could you please re-review?

Swiddis

One issue, a few suggestions & polish

github-actions · 2026-05-19T07:55:54Z

Persistent review updated to latest commit 8b3962e

github-actions · 2026-05-19T08:43:31Z

Persistent review updated to latest commit 05e612c

github-actions · 2026-05-20T08:38:49Z

Persistent review updated to latest commit c007980

ishag4 · 2026-05-20T09:25:44Z

Hi @Swiddis @LantaoJin @penghuo, could you please re-review? A few pipelines were failing, and I’ve pushed the necessary fixes. The workflows are now awaiting approval.

Signed-off-by: Isha Gupta <igupta24@apple.com>

github-actions · 2026-05-20T09:57:30Z

Persistent review updated to latest commit 7194590

github-actions · 2026-07-22T09:25:39Z

Persistent review updated to latest commit b718cb6

mengweieric · 2026-08-04T18:24:16Z

@ishag4 please check failing CIs

Signed-off-by: Isha Gupta <igupta24@apple.com>

github-actions · 2026-08-11T15:54:38Z

Persistent review updated to latest commit 282b487

ishag4 · 2026-08-11T16:00:17Z

Hi @mengweieric Can you please re-trigger the CIs?

ishag4 · 2026-08-11T18:04:33Z

Hi @mengweieric @Swiddis @LantaoJin @penghuo Could you please review and approve this PR?

Signed-off-by: Isha Gupta <igupta24@apple.com>

…-5235

github-actions · 2026-08-14T21:44:17Z

Persistent review updated to latest commit 9c67c76

Add include_metadata request parameter for PPL queries opensearch-pro…

c8f2103

…ject#5235 Signed-off-by: Isha Gupta <igupta24@apple.com>

ishag4 requested review from LantaoJin, RyanL1997, Swiddis, acarbonetto, ahkcs, anirudha, dai-chen, joshuali925, mengweieric, noCharger, penghuo, ps48, qianheng-aws, songkant-aws, vamsimanohar, ykmr1224 and yuancu as code owners May 6, 2026 19:40

LantaoJin reviewed May 12, 2026

View reviewed changes

Comment thread ppl/src/test/java/org/opensearch/sql/ppl/calcite/CalcitePPLFlattenTest.java Outdated

added integration tests, endpoint.md and flatten fix

85f18b2

Signed-off-by: Isha Gupta <igupta24@apple.com>

ishag4 force-pushed the issue-5235 branch from 6028130 to 85f18b2 Compare May 17, 2026 07:29

Swiddis requested changes May 18, 2026

View reviewed changes

ishag4 force-pushed the issue-5235 branch from b79855b to 8b3962e Compare May 19, 2026 07:54

ishag4 force-pushed the issue-5235 branch from 8b3962e to 05e612c Compare May 19, 2026 08:41

Swiddis previously approved these changes May 19, 2026

View reviewed changes

ishag4 dismissed Swiddis’s stale review via c007980 May 20, 2026 08:37

ishag4 force-pushed the issue-5235 branch from 05e612c to c007980 Compare May 20, 2026 08:37

ishag4 force-pushed the issue-5235 branch from c007980 to 4f001a6 Compare May 20, 2026 09:23

fixed pipeline failures

7194590

Signed-off-by: Isha Gupta <igupta24@apple.com>

ishag4 force-pushed the issue-5235 branch from 4f001a6 to 7194590 Compare May 20, 2026 09:55

mengweieric added feature PPL Piped processing language labels Aug 4, 2026

fixed failing CIs

282b487

Signed-off-by: Isha Gupta <igupta24@apple.com>

ishag4 force-pushed the issue-5235 branch from b718cb6 to 282b487 Compare August 11, 2026 15:52

dai-chen reviewed Aug 14, 2026

View reviewed changes

Comment thread docs/user/ppl/interfaces/endpoint.md Outdated

Isha Gupta added 2 commits August 15, 2026 03:07

fixed doc

77af5b9

Signed-off-by: Isha Gupta <igupta24@apple.com>

Merge branch 'issue-5235' of https://github.com/ishag4/sql into issue…

9c67c76

…-5235

Uh oh!

Conversation

ishag4 commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issues

Check List

Uh oh!

github-actions Bot commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Reviewer Guide 🔍

(Review updated until commit 9c67c76)

Uh oh!

github-actions Bot commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Code Suggestions ✨

Previous suggestions

Uh oh!

ishag4 commented May 8, 2026

Uh oh!

LantaoJin left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot commented May 17, 2026

Uh oh!

ishag4 commented May 17, 2026

Uh oh!

Swiddis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented May 19, 2026

Uh oh!

github-actions Bot commented May 19, 2026

Uh oh!

github-actions Bot commented May 20, 2026

Uh oh!

ishag4 commented May 20, 2026

Uh oh!

github-actions Bot commented May 20, 2026

Uh oh!

github-actions Bot commented Jul 22, 2026

Uh oh!

mengweieric commented Aug 4, 2026

Uh oh!

github-actions Bot commented Aug 11, 2026

Uh oh!

ishag4 commented Aug 11, 2026

Uh oh!

ishag4 commented Aug 11, 2026

Uh oh!

Uh oh!

github-actions Bot commented Aug 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ishag4 commented May 6, 2026 •

edited

Loading

github-actions Bot commented May 6, 2026 •

edited

Loading

(Review updated until commit `9c67c76`)

github-actions Bot commented May 6, 2026 •

edited

Loading