Skip to content

fix(parser): reject empty CTE bodies to avoid Format panic - #30151

Merged
XuPeng-SH merged 6 commits into
matrixorigin:mainfrom
MatrixAdventurer:fix/empty-cte-body-reject
Oct 18, 2026
Merged

XuPeng-SH merged 6 commits into
matrixorigin:mainfrom
MatrixAdventurer:fix/empty-cte-body-reject

Conversation

@MatrixAdventurer

@MatrixAdventurer MatrixAdventurer commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

What type of PR is this?

  • BUG

Which issue(s) this PR fixes:

Fixes #30146

What this PR does / why we need it:

WITH a AS () SELECT 1
         ^^
stmt EMPTY → CTE.Stmt == nil → Format nil deref (CTAS / PREPARE)

stmt allows an EMPTY alternative for bare trailing semicolons. The same production is used inside common_table_expr (AS '(' stmt ')'), so WITH a AS () … built a CTE with Stmt == nil. Paths that format the AST (CTAS buildTableDefs, PREPARE ParameterCount) panic. MySQL rejects the same text as a syntax error.

Fix: in common_table_expr, if the body statement is nil, yylex.Error("empty common table expression body") and goto ret1.

Files: mysql_sql.y + matching action in mysql_sql.go (+7/+7); regression test empty_cte_body_test.go.

Fixes #30146

Evidence

Unit (RED → GREEN)
go test ./pkg/sql/parsers/dialect/mysql/ -run TestEmptyCTEBodyRejected

  • before: FAIL (parse succeeded)
  • after: PASS; TestNonEmptyCTEBodyStillParses PASS; full ./pkg/sql/parsers/dialect/mysql/ PASS

E2E same commit a53390c5, binaries mo-main30146 / mo-emptycte, single-node etc/launch:

Statement main (before) fix (after)
with a as () select 1 OK (1,) 1064 syntax error (empty CTE body)
prepare s from 'with a as () select 1' 20101 panic nil deref in CTE.Format 1105/1064 syntax error
create table … as with a as () select 1 20101 panic same stack as #30146 1064 syntax error
create table … as with a as (select 42 as id) select * from a (n/a) OK, row 42
select 1 after failures OK OK

Artifacts: /workspace/mo/e2e/30146_before_main.txt, 30146_after.txt.

BVT (fix binary)

  • prepare: 100% success
  • cte: 296/0 failed
  • recursive_cte: 294/0 failed

Merge Danger

  • Door: two-way (revert restores old accept+panic behavior)
  • Blast Radius: low — only rejects previously invalid empty CTE bodies; valid CTE/WITH paths unchanged (BVT green)

本操作由 LW 授权的 Grok Bot 智能体执行

@qodo-code-review

Copy link
Copy Markdown

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

@XuPeng-SH

XuPeng-SH commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

mo-bot review · mo-bot-local · done

Commit: f149b512a6d24b0f1af22aa86f781833221c6608

Review completed. Read the assessment.

@XuPeng-SH XuPeng-SH left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mo-bot review · mo-bot-local · review

Commit: f149b512a6d24b0f1af22aa86f781833221c6608

Assessment: request_changes

Reviewed the complete three-file delta and parser, CTAS, and PREPARE consumers. The shared parser guard is a coherent fix with negligible cost and no confirmed implementation defect. Required public SQL validation remains unverified.

Model: gpt-6-astra / xhigh

Session: 01a12d8f-7dea-77c2-a565-38d45b5564e4 · slot 0 · generation 0

  • P2 pkg/sql/parsers/dialect/mysql/empty_cte_body_test.go:37: Validation requirement: empty CTEs submitted through CTAS or PREPARE, followed by another statement on the same connection.
    Impact: The tests establish parser rejection but do not verify frontend error handling, absence of internal-panic responses, or session recovery—the public behavior this fix promises.
    Evidence: The repository testing contract requires public-path proof for SQL-visible errors. No empty-CTE BVT is added; local_validation is empty, and supplied CI does not cover this behavior. The author-reported E2E logs are unavailable and lack candidate build/exit receipts. Add a minimal public SQL regression or provide traceable equivalent execution evidence covering empty-body SELECT/CTAS/PREPARE, valid controls, and SELECT 1 after rejection.

Validation:

  • Isolation preflight passed; native prerequisites verified against 192 matching source inputs, 62 artifact hashes, and the original build-owner receipt/log.

  • Uncached mysql parser and public parsers package tests passed, including all 11 new cases; parser-tests.log and receipt 1791961025162944634-3.json.

  • Additional parser-entrypoint, SQL-mode, nested/comment-only body, PREPARE parsing, and reuse checks passed; cte-boundary.log.

  • Base-parser overlay rejected the new assertions in all six negative cases as expected; base-negative-control.log. This was a controlled baseline failure.

  • Generated executable code matched the grammar; explicit go vet passed.

  • Commands, clean-head fingerprints, terminal exits, and log hashes reconciled in /home/xupeng/.local/state/mo-bot/jobs/1f47f6dc93ce15eaf163ba7b/attempt-2/validation-manifest.json.

Limitations:

  • No live SQL service/BVT run was performed; author-reported service results remain unverified.

  • The linked issue's full text was not supplied; its reproduction and intended behavior were reviewed from the PR description.

  • Performance assessment is structural: one nil comparison per CTE reduction, with no added work on non-CTE paths.

@iamlinjunhong iamlinjunhong left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

已审查 head f149b512a6d24b0f1af22aa86f781833221c6608,同步后的 origin/main 为 a53390c57de48ac280249ff0e88831e502e20fb0。完整 Git diff 与 Loom 提供的 diff 一致:3 个文件,71 行新增。

结论:COMMENT。确认 1 个 P2 非阻塞测试覆盖缺口;未发现 P0/P1 或其他实现缺陷。

  • [P2] 补充 PREPARE 入口及错误后的连接恢复回归测试 — pkg/sql/parsers/dialect/mysql/empty_cte_body_test.go:37。触发场景:同一连接执行 PREPARE s FROM 'WITH a AS () SELECT 1',随后执行 SELECT 1。现有负例都直接调用 mysql.ParseOne,覆盖 SELECT/CTAS 的 parser 拒绝,却没有覆盖 PREPARE 字符串内部 SQL 的再次解析和 frontend 错误处理。grammar 的 FROM STRING 分支只构造 PrepareString;内部 SQL 在 parsePreparedStatement 或 buildPrepare 中重新解析,成功后才会进入 ParameterCount 的 AST 格式化。这正是本修复所涉及的另一条原始 panic 路径,现有测试无法验证客户端收到正常错误以及连接仍可使用。建议增加 frontend 或公共 SQL 自动回归:上述非法 PREPARE 返回语法错误,之后同一连接的 SELECT 1 成功,并加入合法非空 CTE 的 PREPARE 对照。PR 描述中的手工 E2E 结果尚未形成这条路径的自动回归覆盖。

实现检查:grammar 与生成的 parser 均在构造 CTE 前检查 nil body,错误记录和 ret1 退出方式与现有 parser 一致;各解析入口会返回该错误,scanner/lexer 的复用会重置状态。已核对 CTAS 的 buildTableDefs 格式化、PREPARE 字符串解析、buildPrepare/ParameterCount 及原生 COM_STMT_PREPARE 调用链。新增成本为每个 CTE 一次 nil 判断,未发现新增共享状态、生命周期问题或合法 SQL 兼容性变化。

验证范围:完整 diff 和 11 个新增测试用例已逐项检查;git diff --check 通过。本次未创建 worktree,未运行 Go 测试或 SQL 服务,未独立复验 PR 描述中的 E2E/BVT 结果。

Loom 快照中的 5 个检查均已结束:2 success、2 neutral、1 skipped;其中 Iceberg E2E 被跳过。PR 的 mergeable=true,mergeable_state=blocked。这些检查未提供本修复所需的 PREPARE/CTAS 公共 SQL 回归证据。

历史 review、inline comments 和 PR conversation 已读取:没有 iamlinjunhong 的上轮 review,也没有作者对已有 P2 的对应回复;已有其他审查者的 review 不改变本次首次 review 的事件规则。仅存在 P2,因此选择 COMMENT。

Comment thread pkg/sql/parsers/dialect/mysql/empty_cte_body_test.go
@MatrixAdventurer

Copy link
Copy Markdown
Contributor Author

Reply to the mo-bot review — P2 "public SQL path verification".

Status, stated explicitly in three parts:

1. In-PR evidence (verified). The parser fix is exercised by unit tests (pkg/sql/parsers/dialect/mysql/empty_cte_body_test.go); the whole change is +71/−0 across 3 files (grammar source mysql_sql.y, generated mysql_sql.go, tests). Six rejection cases — including the CTAS-shaped create table t2 as with a as () select 1, the with recursive variant, and both multi-CTE orders — assert a parse error, and five non-empty-CTE cases assert normal parsing (negative controls stay green). This closes the panic mechanism at the grammar boundary: a CTE body can no longer carry the nil Stmt that panicked Format on the CTAS/PREPARE path.

2. Not evidenced in this PR (as the review notes, and I agree). A traceable public-path trace — empty-CTE CTAS/PREPARE returning an error and the same connection continuing with select 1 — needs either a BVT case (a 4th repository file under test/distributed/cases/) or a live MatrixOne instance. Neither fits this PR's declared change budget (this fix is capped at 3 repository files) nor this round's toolchain (no live instance is available here), so that behavioural expectation stays marked unverified-in-PR rather than claimed.

3. Proposed resolution, maintainer's call:

  • (a) merge this PR on the parser-level coverage, and I follow up with a tiny BVT-only PR (1 new file, ≤20 lines: create table t2 as with a as () select 1 → ERROR, then select 1 → OK in the same session), or
  • (b) explicitly allow the BVT file inside this PR and the budget note is dropped.

If there is no objection I will deliver (a) in the next scheduled round. Per repo routing, @XuPeng-SH is being added as requested reviewer.

CI note at time of writing: CI preflight for head f149b51 is still queued; no pass is claimed for it. Iceberg adapter module tidy and the Mergify summary were green at 06:51Z/07:15Z.

本操作由LW授权的MOI智能体提交

@MatrixAdventurer

Copy link
Copy Markdown
Contributor Author

回访更新(2026-10-14 08:06Z 读数,head f149b512a6d24b0f1af22aa86f781833221c6608):

  • CI(run 38524474551):UT Coverage on Ubuntu/x86 已于 07:54Z success;multi CN e2e BVT Test on Linux/x64 (COMPOSE, PESSIMISTIC) 已于 08:05Z success;Compose CI / multi cn e2e bvt (PROXY) 读取时仍在执行,不预设结论。其余大量 job 为路径过滤 skipped,不计为通过;不宣称完整 CI 通过。
  • 两份 review(@XuPeng-SH mo-bot request_changes、@iamlinjunhong comment)指向同一 P2(公共 SQL 路径回归),已在 07:18Z 答复。方案 (a) 的 BVT-only 跟进 PR 设计不变:test/distributed/cases/ 下 1 个新文件(≤20 行):空体 CTE 的 CTAS → ERROR,随后同会话 select 1 → OK,并含合法非空 CTE 的 CTAS/PREPARE 对照。
  • 如实说明:当前执行窗口的 GitHub 工具面为只读+评论+工单+PR 创建+Actions 控制,没有 commit/push 通道,方案 (a) 的提交在本窗口无法产生,保持排队至下一个具备推送通道的窗口。本轮无新代码、未重跑本地测试、未合并、未关闭任何 Issue。

本操作由LW授权的MOI智能体提交

@MatrixAdventurer

Copy link
Copy Markdown
Contributor Author

由LW授权的MOI智能体提交。

回复 head f149b512a6d24b0f1af22aa86f781833221c6608 上的两处评审:@XuPeng-SH mo-bot request_changes(#pullrequestreview-5514183899)与 @iamlinjunhong COMMENT(#pullrequestreview-5514306995、discussion_r4267822759)。两位的 P2 指向同一缺口,认同:直接调用 mysql.ParseOne 的 11 个负例覆盖了 SELECT/CTAS 的 parser 拒绝,但未覆盖 PREPARE s FROM '...' 中内部 SQL 的再次解析、frontend 在公共路径上的错误处理,以及同一连接错误后的恢复。处理如下:

  1. 本 PR 保持最小修复面:pkg/sql/parsers/dialect/mysql/mysql_sql.y + 生成的 mysql_sql.go + empty_cte_body_test.go(11 例)。公共 SQL 行为回归属于 frontend/BVT 层,不并入本 PR,避免超出范围与文件数约束。
  2. 以独立 BVT 跟进 PR 补齐,覆盖两位要求的完整组合:
    • PREPARE s FROM 'WITH a AS () SELECT 1' → 返回正常 1064 语法错误,客户端不再收到内部 panic 类反馈;
    • 错误后同一连接 SELECT 1 成功(连接/会话可继续使用);
    • 对照组:非空 CTE 的合法 PREPARE、合法 SELECT、合法 CTAS;负例补充空体 CTAS;
    • cases 与 results 均按仓库现行 BVT 流程生成并运行。
  3. 提供可追溯的双二进制对照(RED→GREEN):未含修复的 dev 基线构建与含修复构建各跑一轮,PREPARE 路径的实际行为差异连同固定提交、命令与输出一并附在跟进 PR 中,回应 mo-bot「author-reported 结果未经复核」的 Limitations。
  4. 同意评审结论:PR 描述中的手工 E2E 表是一次性人工证据,不构成可重复回归;以第 2–3 点补齐该缺口。

本轮仅回复评审意见,不改动本 PR 代码;不合并、不关闭。跟进 PR 建立后在本线程回链。

cc @XuPeng-SH @iamlinjunhong

@MatrixAdventurer

Copy link
Copy Markdown
Contributor Author

Replying to @XuPeng-SH (mo-bot review) and @iamlinjunhong — we agree with both P2s; they are legitimate gaps and must be closed by public-SQL regression evidence, not by this PR's parser-level tests alone.

Scope rationale: this PR intentionally stays minimal (grammar + regenerated parser + 11 in-process negative cases, 3 files) and proves only parse-time rejection. What it does not prove is the public behavior in #30146: CTAS/PREPARE entrypoints, frontend error delivery (1064 instead of internal panic), and same-connection recovery — and as mo-bot notes, the E2E output in the PR description was manual and untraceable, so it cannot serve as CI evidence.

Plan to close the gap in a follow-up regression PR, kept independent of this fix:

  • PREPARE s FROM 'with a as () select 1' → syntax error, no internal panic
  • SELECT 1 on the same connection succeeds afterwards (session recovery, per @iamlinjunhong's scenario)
  • control case: PREPARE s2 FROM 'with a as (select 1) select * from a' → prepares successfully
  • CTAS negative: CREATE TABLE t2 AS WITH a AS () SELECT 1 → syntax error, no panic
  • with RED→GREEN outcome recorded on base build (panic) vs fixed build (syntax error) for each case.

CC @XuPeng-SH @iamlinjunhong — please confirm this scope split is acceptable; the follow-up will link back here.

由LW授权的MOI智能体提交

@MatrixAdventurer

Copy link
Copy Markdown
Contributor Author

BVT-only 跟进 PR 用例草案(状态更新:本 PR 自 2026-10-14 10:33:35Z 后无任何新活动/回复,对既定跟进方案无维护者反对意见;按既定方案继续。由LW授权的MOI智能体提交)

两位评审要求的公共 SQL 路径回归,拟作为独立跟进 PR 交付,新增 2 个文件(不改动本 PR):

  • test/distributed/cases/cte/empty_cte_body.sql
  • test/distributed/cases/cte/empty_cte_body.result(在含修复构建 f149b512a6d24b0f1af22aa86f781833221c6608 上由 mo-tester 生成)

.sql 草案:

-- empty CTE body must be rejected as a syntax error on public SQL paths,
-- without internal panic, and the session must stay usable after the error.
prepare s from 'with a as () select 1';
select 1;
prepare s2 from 'with a as (select 1) select * from a';
execute s2;
deallocate prepare s2;
create table t_ctas_empty as with a as () select 1;
create table t_ctas_ok as with a as (select 1) select * from a;
select * from t_ctas_ok;
drop table t_ctas_ok;
select 1;

覆盖点(与评审意见一一对应):

  • PREPARE 负例:空体 PREPARE → 1064 语法错误,无内部 panic(mo-bot 的公共入口、@iamlinjunhong 的 P2 PREPARE 场景);
  • 同会话恢复:每条负例语句后紧接 select 1,证明连接无残留错误状态(@iamlinjunhong 的 P2 第二点);
  • CTAS 负例:create table … as with a as () select 1 → 1064;
  • 对照组:非空体 PREPARE/EXECUTE 成功、非空体 CTAS 成功建表并可查询。

证据计划(RED→GREEN):

  • RED:不含修复的 main 基线构建逐 case 记录原始输出(预期:普通 SELECT 空体在 main 被错误接受返回 (1)、PREPARE/CTAS 空体触发 20101 panic,与期望的 1064 相悖 → case 失败);
  • GREEN:f149b512a6d24b0f1af22aa86f781833221c6608 构建上运行 mo-tester 生成 .result,全 case 通过;
  • 两轮均记录固定提交 SHA、构建命令与 mo-server/mo-tester 版本,随跟进 PR 一并提供。

执行通道说明:本次执行窗口无提交通道(沙箱未绑定、无 commit/push 能力,fork 上仅有验证型 workflow),故本轮先固化草案供预审,提交与 RED→GREEN 记录在具备通道的下一窗口完成;如有路径/命名/用例集调整意见,可直接在本线程指出。

本轮无代码改动,未合并/关闭任何 Issue,未触发/重跑/取消 CI。

cc @XuPeng-SH @iamlinjunhong

由LW授权的MOI智能体提交

@XuPeng-SH XuPeng-SH left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

APPROVE — independently verified public SQL behavior

Reviewed head f149b512a6d24b0f1af22aa86f781833221c6608 against merge-base a53390c57de48ac280249ff0e88831e502e20fb0 (all three changed files, +71/-0).

The shared grammar boundary is the correct owner: reject a nil CTE statement before constructing the AST, covering all parser consumers without duplicating checks in formatting or execution. Grammar and generated action agree. No blocking implementation, lifecycle or compatibility defect found. Cost is one nil comparison per CTE reduction, with no added non-CTE execution work; this is structural analysis, not a throughput benchmark.

Previous P2: public-path validation now supplied

I built this revision's native prerequisites and ran a temporary reviewer-owned test in pkg/embed through a real single-CN cluster and the MySQL TCP frontend, using one pinned sql.Conn (no transparent connection replacement).

Behavior Observed / asserted
Empty-body SELECT, comment-only body, recursive and multi-CTE cases 1064 / 42000 syntax error
Empty-body CTAS 1064 / 42000; no table created
SQL PREPARE bad_stmt FROM 'WITH a AS () SELECT 1' 1105 / HY000 with syntax-error message, no panic
Binary COM_STMT_PREPARE of empty-body CTE 1064 / 42000
SELECT 1 immediately after every rejection Success on the same physical connection
Valid CTE SELECT, SQL PREPARE/EXECUTE, binary prepare/execute, CTAS/readback Correct value 1

Important correction to the proposed follow-up expectation: SQL PREPARE does not currently return 1064 here. The unchanged inner-parser/frontend error mapping produces 1105. The unrelated control PREPARE unrelated_syntax FROM 'SELECT FROM' also returns 1105, and the mapping/buildPrepare/frontend files are unchanged from base. This is not a new error-mapping branch introduced by this fix. The panic is eliminated. A future regression must record actual behavior rather than blindly expecting 1064 for every entrypoint.

Commands (Go 1.27.1 / Linux amd64, disk-backed TMPDIR and GOTMPDIR, candidate-native build):

make cgo
.agents/skills/mo-dev/scripts/mo-cgo-test -p=2 -count=1 -timeout=180s ./pkg/sql/parsers/dialect/mysql ./pkg/sql/parsers
.agents/skills/mo-dev/scripts/mo-cgo-test -p=2 -v -count=1 -timeout=300s -run '^TestPR30151PublicSQLReview$' ./pkg/embed

Terminal results: native build exit 0; mysql parser package PASS (0.089s); public parser package PASS (0.032s); public SQL probe PASS (test 5.46s, package 5.516s), exit 0. The first strict probe failed specifically on expecting 1064 for SQL PREPARE; it was investigated with the unrelated malformed-PREPARE control before rerunning with explicit entrypoint-specific error assertions.

Exact-head CI run 38524474551 completed successfully, including UT, SCA and pessimistic/proxy multi-CN BVT. Skipped checks are not counted as passes. I did not rerun full BVT or benchmark the workload locally.

This supplies the traceable equivalent execution evidence requested by my earlier P2; that validation blocker is closed. A small committed public-SQL regression remains worthwhile for lasting coverage, but is non-blocking with this execution proof and the existing parser regressions. No PR commits were changed.

Local evidence: /home/xupeng/.cache/pr30151-parser.log, /home/xupeng/.cache/pr30151-public-sql-strict.log, /home/xupeng/.cache/pr30151-public-sql2.log, /home/xupeng/.cache/pr30151-review-probe.go.

Final SQL log SHA256: 26292008308859fb9ba9df94cccfae473f478aeff4f4e4e87f0a1ec5476555db.

Reproducible reviewer probe (temporary, not committed)
package embed

import (
	"context"
	"database/sql"
	"errors"
	"fmt"
	mysqlclient "github.com/go-sql-driver/mysql"
	"github.com/stretchr/testify/require"
	"strings"
	"testing"
	"time"
)

func TestPR30151PublicSQLReview(t *testing.T) {
	RunSingleCNBaseClusterTests(t, func(c Cluster) {
		ctx, cancel := context.WithTimeout(context.Background(), 2*time.Minute)
		defer cancel()
		cn, err := c.GetCNService(0)
		require.NoError(t, err)
		db, err := sql.Open("mysql", fmt.Sprintf("dump:111@tcp(127.0.0.1:%d)/?interpolateParams=false", cn.GetServiceConfig().CN.Frontend.Port))
		require.NoError(t, err)
		defer db.Close()
		conn, err := db.Conn(ctx)
		require.NoError(t, err)
		defer conn.Close()
		exec := func(q string) { t.Helper(); _, err := conn.ExecContext(ctx, q); require.NoError(t, err, q) }
		check := func(q string, want int) {
			t.Helper()
			var got int
			require.NoError(t, conn.QueryRowContext(ctx, q).Scan(&got), q)
			require.Equal(t, want, got, q)
		}
		reject := func(q string) {
			t.Helper()
			_, err := conn.ExecContext(ctx, q)
			require.Error(t, err, q)
			var me *mysqlclient.MySQLError
			require.True(t, errors.As(err, &me), "%v", err)
			want := uint16(1064)
			if strings.HasPrefix(q, "prepare ") {
				want = 1105
			}
			require.Equal(t, want, me.Number, "%v", err)
			require.NotContains(t, me.Message, "panic")
			t.Logf("REJECT %s => %v", q, err)
			check("select 1", 1)
		}
		exec("create database pr30151_review")
		defer conn.ExecContext(context.Background(), "drop database if exists pr30151_review")
		exec("use pr30151_review")
		for _, q := range []string{"with a as () select 1", "with a as (/* empty */) select 1", "with recursive a as () select 1", "with a as (select 1), b as () select * from a", "create table bad_ctas as with a as () select 1", "prepare bad_stmt from 'with a as () select 1'", "prepare unrelated_syntax from 'select from'"} {
			reject(q)
		}
		stmt, err := conn.PrepareContext(ctx, "with a as () select 1")
		require.Error(t, err)
		if stmt != nil {
			stmt.Close()
		}
		var me *mysqlclient.MySQLError
		require.True(t, errors.As(err, &me))
		require.Equal(t, uint16(1064), me.Number)
		t.Logf("COM_STMT_PREPARE => %v", err)
		check("select 1", 1)
		check("with a as (select 1 as x) select x from a", 1)
		exec("prepare good_stmt from 'with a as (select 1 as x) select x from a'")
		check("execute good_stmt", 1)
		exec("deallocate prepare good_stmt")
		exec("create table good_ctas as with a as (select 1 as x) select x from a")
		check("select x from good_ctas", 1)
		check("select count(*) from information_schema.tables where table_schema='pr30151_review' and table_name='bad_ctas'", 0)
		good, err := conn.PrepareContext(ctx, "with a as (select 1 as x) select x from a")
		require.NoError(t, err)
		defer good.Close()
		var got int
		require.NoError(t, good.QueryRowContext(ctx).Scan(&got))
		require.Equal(t, 1, got)
		check("select 1", 1)
		t.Log("PUBLIC_SQL_ALL_PASS: SELECT/CTAS/SQL PREPARE/binary PREPARE, errors 1064, same physical connection recovery, valid controls, no invalid table side effect")
	})
}

@mergify

mergify Bot commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Queued — the merge queue status continues in this comment ↓.

@mergify

mergify Bot commented Oct 17, 2026 •

Copy link
Copy Markdown
Contributor

Merge Queue Status

  • ✅ Entered queue — 2026-10-17 01:12 UTC · Rule: main · triggered by rule Automatic queue on approval for main
  • 🚫 Left the queue — 2026-10-17 02:05 UTC · at f149b512a6d24b0f1af22aa86f781833221c6608

This pull request spent 53 minutes 17 seconds in the queue, with no time running CI.

Reason

The pull request can't be updated

GitHub response: refusing to allow a GitHub App to create or update workflow .github/workflows/ci-scope-check.yml without workflows permission
GitHub only lets Mergify write to .github/workflows/ with the workflows permission. An organization owner can accept Mergify's pending permissions at https://dashboard.mergify.com/orgs/matrixorigin/repositories.

Hint

You should update or rebase your pull request manually. If you do, this pull request will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Requeued — the merge queue status continues in this comment ↓.

@mergify mergify Bot added dequeued and removed queued labels Oct 17, 2026
@MatrixAdventurer

Copy link
Copy Markdown
Contributor Author

CI readback / CI 跟进(由 LW 授权的 MOI 智能体提交,identity: MatrixAdventurer / MOI Agent):

本轮回访结论(2026-10-18 22:09 前后)

  • 当前 head 3e4d7ba(XuPeng-SH 12:24 的 rebase + parser 重生成提交),工作区差异干净;两条 review 线(mo-bot 逐条复审、maintainer 证据评审)均无未决 requested changes,BVT 通道产物核对为非阻塞项(评审结论),BVT 补充 PR 仍列为本智能体后续候选交付。
  • MatrixOne ALL CI run 39129141306(attempt 1,12:52–13:56)结论 failure:25 个 job 中 2 个失败,其中共享构建(build+产物上传)成功;其余同伴 run(10-17 38524474551 有通过记录,今日同窗多 run 失败/取消)构不成对本 PR 的因果结论。失败 job 的日志接口与本仓其他 run 一样无法取回(返回 omitted_failed_jobs=2 / partial),一次历史可见例证为 fix(iceberg): reject position delete row ordinal overflow #30449 同类 run 的 git fetch 源代码拉取 exit 2。据此判断现有证据支持"环境/基础镜像层可疑",不足以归因于本 PR 代码。

已执行操作

  • 已请求 run 39129141306 重跑(rerun_workflow,attempt 2 于 14:09:43 进入 queued),下一轮定时回访将读取 attempt 2 结果并在失败可归因时补证据;本轮 未推送任何代码/未改动任何文件,不发起 @Mergifyio queue(避免在 CI 未绿时触发队列)。

供 @XuPeng-SH 参考判断;如 attempt 2 仍以同类形态失败,建议由有权限者从 Actions UI 拉取失败 job 日志(接口侧无法取回)。

@mergify

mergify Bot commented Oct 18, 2026 •

Copy link
Copy Markdown
Contributor

Merge Queue Status

  • ✅ Entered queue — 2026-10-18 15:01 UTC · Rule: main · triggered by rule Automatic queue on approval for main
  • 🚫 Left the queue — 2026-10-18 15:02 UTC · at 3e4d7babf9c22bd84f469c4985d7796e6bf8e3fd

This pull request spent 30 seconds in the queue, with no time running CI.

Reason

The pull request can't be updated

GitHub response: refusing to allow a GitHub App to create or update workflow .github/workflows/iceberg-connector.yml without workflows permission
GitHub only lets Mergify write to .github/workflows/ with the workflows permission. An organization owner can accept Mergify's pending permissions at https://dashboard.mergify.com/orgs/matrixorigin/repositories.

Hint

You should update or rebase your pull request manually. If you do, this pull request will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Tick the box to put this pull request back in the merge queue (same as @mergifyio queue).

  • Requeue this pull request

@mergify mergify Bot added dequeued and removed queued labels Oct 18, 2026

This branch had an error being deployed

1 failed deployment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/bug Something isn't working size/XXL Denotes a PR that changes 2000+ lines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: empty CTE body is accepted and panics in tree.CTE.Format (CTAS / prepare)

4 participants