[BUG] Double appendpipe causes 'different planner' assertion due to AST re-visitation

[penghuo]

Query Information

PPL Command/Query:

source=bounty-numbers | appendpipe [stats avg(value) as avg_val] | appendpipe [stats max(value) as max_val]

Expected Result:
Query should execute and return appended aggregation output without planner failure.

Actual Result:
HTTP 400 assertion error:
Relational expression ... belongs to a different planner than is currently being used.

Dataset Information

Dataset/Schema Type

• OpenTelemetry (OTEL)
• Simple Schema for Observability (SS4O)
• Open Cybersecurity Schema Framework (OCSF)
• Custom (details below)

Index Mapping

{
  "mappings": {
    "properties": {
      "count": { "type": "integer" },
      "category": { "type": "keyword" },
      "subcategory": { "type": "keyword" },
      "value": { "type": "double" },
      "ts": { "type": "date" }
    }
  }
}

Sample Data

[
  { "count": 1, "category": "A", "subcategory": "X", "value": 10.5, "ts": "2024-01-01" },
  { "count": 2, "category": "A", "subcategory": "Y", "value": 20.3, "ts": "2024-01-02" },
  { "count": 10, "category": "B", "subcategory": "X", "value": 100.0, "ts": "2024-01-03" }
]

Bug Description

Issue Summary:
Chained appendpipe triggers planner mismatch assertion.

Steps to Reproduce:

1. Create index and insert sample rows.
2. Run the query above.
3. Observe HTTP 400 assertion about different planner.

Impact:
Multi-stage appendpipe transformations fail and break query pipelines.

[songkant-aws]

Not all of double appendpipe will trigger this assertion error. It's triggered when Calcite prepares statement and also tries to trim fields to early optimize logical plans. Some part of RelNodes are created in a complex path by a different planner. During plan optimization, the RelSets don't accept nodes created by different planners and assert on that.

See a workaround fix (but should be enough) in #5322. The trim fields optimization is not lost because it will be done once more in optimization phase.