[Bug] [Nereids] "fragment has no children" error when INSERT INTO / CTAS with RECURSIVE CTE

[wangchen2019]

Search before asking

• I had searched in the issues and found no similar issues.

Version

create table tmps.tmp_trace_link_long_magnetic_sort PROPERTIES ( "replication_num" = "2" ) as with recursive t(id, a) as ( select cast(1 as bigint), array(cast(1 as bigint))

union all

select
id + 1,
array_pushback(a, id)
from t
where id < 5
) select * from t;

What's Wrong?

SQL 错误 [1105] [HY000]: fragment has no children

What You Expected?

-- 1. 显式建表（明确指定字段类型）
drop table tmps.tmp_trace_link_long_magnetic_sort;
CREATE TABLE tmps.tmp_trace_link_long_magnetic_sort (
id BIGINT,
a ARRAY
)
PROPERTIES (
"replication_num" = "2"
);

-- 方法 1：直接关闭 Nereids 优化器（推荐）
SET enable_nereids_planner = false;

-- 方法 2：如果方法 1 报错，尝试开启自动回退机制
SET enable_fallback_to_original_planner = true;

-- 2. 插入数据
INSERT INTO tmps.tmp_trace_link_long_magnetic_sort
WITH RECURSIVE t(id, a) AS (
SELECT
CAST(1 AS BIGINT),
array(CAST(1 AS BIGINT))
UNION ALL
SELECT
id + 1,
array_pushback(a, id)
FROM t
WHERE id < 5
)
SELECT * FROM t;

SQL 错误 [1105] [HY000]: fragment has no children

How to Reproduce?

No response

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_e2a93862adf5

Initial read: this looks like a real FE planner/coordinator bug, not a SQL syntax issue.

The issue does not provide an actual Doris version; the "Version" field contains the CTAS SQL. I checked current apache/doris upstream master (e8c06f265a2) for the relevant path. The exact error text comes from Coordinator.findMaxParallelFragmentIndex(), which asserts that a fragment with no leftmost ScanNode must have at least one child fragment:

Preconditions.checkState(!fragment.getChildren().isEmpty(), "fragment has no children")

The reporter's recursive CTE has a special shape:

WITH RECURSIVE t(id, a) AS (
  SELECT CAST(1 AS BIGINT), array(CAST(1 AS BIGINT))
  UNION ALL
  SELECT id + 1, array_pushback(a, id) FROM t WHERE id < 5
)

There is no real base table scan in either the anchor side or recursive side. In Nereids translation, the anchor constant select is translated through a one-row/union fragment, and the recursive reference is translated to RecursiveCteScanNode, which extends PlanNode, not ScanNode. PhysicalPlanTranslator.visitPhysicalRecursiveUnion() then sets the recursive CTE fragment root to RecursiveCteNode and marks the fragment as UNPARTITIONED.

That can produce a recursive CTE fragment where:

1. the leftmost node is not a ScanNode, because it is under RecursiveCteNode / RecursiveCteScanNode; and
2. there is no child PlanFragment, because this minimal recursive CTE does not read a base table or introduce an exchange-producing child.

The legacy Coordinator assignment code treats this as "Case B" and calls findMaxParallelFragmentIndex(), but that helper assumes at least one child fragment. That matches the reported fragment has no children error exactly.

Existing upstream regression coverage seems incomplete for this shape. regression-test/suites/recursive_cte/create_and_insert_select_test.groovy covers CTAS and INSERT with recursive CTE over a real OLAP table and join. recursive_100_number_test.groovy covers a constant recursive CTE as a plain SELECT. I did not find coverage for CTAS / INSERT INTO using a pure constant + worktable recursive CTE, especially with an ARRAY<BIGINT> output column.

Suggested maintainer next steps:

1. Add a regression case based on the reporter's SQL for both CTAS and INSERT INTO with an explicit target schema.
2. Check whether the same CTE succeeds as a plain SELECT. If plain SELECT succeeds but CTAS/INSERT fails, the bug is isolated to the insert/load coordinator path.
3. Fix the FE fragment assignment path so recursive CTE fragments without base-table scan children are handled as valid serial/no-scan fragments, or ensure the Nereids distributed coordinator path is used consistently for recursive CTE CTAS/INSERT. The suspicious public code points are PhysicalPlanTranslator.visitPhysicalRecursiveUnion() and Coordinator.findMaxParallelFragmentIndex().

Missing information from the reporter:

1. Actual Doris version or commit hash.
2. Session variable values for enable_nereids_planner, enable_nereids_distribute_planner, enable_fallback_to_original_planner, and local-shuffle related settings.
3. The FE stack trace around the failed statement.
4. Whether the same WITH RECURSIVE ... SELECT * FROM t fails outside CTAS/INSERT.

I would not recommend disabling Nereids as a reliable workaround here. Recursive CTE is a Nereids feature path, and the current code explicitly requires enable_nereids_distribute_planner=true during recursive CTE analysis. A safer temporary workaround is to avoid this pure constant recursive CTE inside CTAS/INSERT, or materialize the rows through another method until the FE fragment assignment bug is fixed.

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_e2a93862adf5

Initial triage: this looks very likely related to #64363, not to the ARRAY<BIGINT> expression or recursive CTE SQL syntax itself.

The issue does not include an actual Doris version; the Version field contains the CTAS SQL. I checked current upstream master (e8c06f265a2) and the public PR above. The exact error text is thrown by Coordinator.findMaxParallelFragmentIndex() when the legacy Coordinator sees a fragment whose leftmost node is not a ScanNode but the fragment has no child fragments. Recursive CTE planning is expected to go through the Nereids distributed planner / NereidsCoordinator path; current recursive CTE analysis also requires enable_nereids_distribute_planner=true.

PR #64363 describes a very close failure mode: in a multi-FE proxy flow, parseByNereids() did not propagate the parsed statement into ConnectContext.getStatementContext(). Then SessionVariable.canUseNereidsDistributePlanner() returned false, Nereids distributed plans were skipped, EnvFactory.createCoordinator() chose the legacy Coordinator, and CTAS with recursive CTE failed with fragment has no children.

Why this issue matches that path:

1. Same error text: fragment has no children.
2. Same statement class: CTAS / INSERT using WITH RECURSIVE.
3. PR [fix](fe) Fix NereidsCoordinator not created in proxy flow due to missing parsedStatement on StatementContext #64363 is still open/draft, so the fix may not be in the reporter's build.

Missing information needed to confirm it:

1. Actual Doris version, commit hash, or build package.
2. Whether the SQL was executed through a follower FE / proxy path or directly on the master FE.
3. Values of enable_nereids_planner, enable_nereids_distribute_planner, and enable_fallback_to_original_planner.
4. The FE stack trace around the failed statement.
5. Whether the same SQL succeeds after applying PR [fix](fe) Fix NereidsCoordinator not created in proxy flow due to missing parsedStatement on StatementContext #64363, or when executed directly on the master FE.

Suggested next steps:

1. If this was run through a multi-FE proxy path, first verify with PR [fix](fe) Fix NereidsCoordinator not created in proxy flow due to missing parsedStatement on StatementContext #64363. If it fixes the case, this issue can be linked to that PR.
2. Add a regression case with the exact CTAS and explicit-schema INSERT INTO from this issue, not only plain SELECT WITH RECURSIVE.
3. If the issue still reproduces on a single FE or after PR [fix](fe) Fix NereidsCoordinator not created in proxy flow due to missing parsedStatement on StatementContext #64363, then investigate the recursive CTE DML sink path separately. The next suspicious area would be fragment/coordinator assignment for recursive CTE plans without a base-table scan.

I would not recommend disabling Nereids as a reliable workaround here. Recursive CTE is a Nereids path, and current code requires the Nereids distributed planner for recursive CTE analysis. A safer temporary workaround is to run against a build containing PR #64363 or execute directly on the master FE if this is confirmed to be the proxy-path case.