Summary

• Location: src/query/service/src/pipelines/builders/builder_project.rs:48
• Panic message: assertion left == right failed: Result projection schema mismatch — left: Nullable(Number(Int64)), right: Number(Int64)

Likely trigger files

DuckDB source tests in the join/left_outer/, join/full_outer/, or join/iejoin/ categories
that produce nullable columns via outer joins. The following files were processed (non-abort)
with gate=fail and contain active outer/range join queries:

• test/sql/join/iejoin/test_iejoin_null_keys.test — LEFT JOIN with inequality conditions, nullable output
• test/sql/join/left_outer/left_join_issue_15316.test — nested LEFT OUTER JOIN
• test/sql/join/full_outer/test_full_outer_join.test — FULL OUTER JOIN (queries commented out but validated during conversion)

Reproduction

The exact SQL is not captured in the panic log, but the call chain is:

SelectInterpreter::execute
  → SelectInterpreter::build_pipeline
    → build_query_pipeline (scheduler.rs:52)
      → PipelineBuilder::build_result_projection (builder_project.rs:48)  ← PANIC

Any SELECT query that goes through a join or subquery producing a nullable Int64 column,
where the optimizer/binder fails to propagate the Nullable wrapper into the final projection schema, will trigger this.

Key stack frames

Root cause

The projection schema expects Number(Int64) but the actual column produced is Nullable(Number(Int64)). The nullable flag is lost somewhere between the binder/optimizer and the pipeline builder.

Fix direction

Trace nullable propagation from join output → optimizer → projection schema. The assert_eq! should also be replaced with a proper ErrorCode return.