iframe-proxy

groeneai · 2026-06-07T12:01:14Z

Fixes a stress-test regression where the server cannot start after attaching a MergeTree table that has a text skip-index part with zero granules: Too many marks in file ...skp_idx_idx.cmrk4, marks expected 0 (bytes size 0).

MergeTreeMarksLoader::loadMarksImpl opens the marks file unconditionally and verifies that the underlying reader is at EOF after the requested number of marks has been consumed. For marks_count == 0 the for-loop runs zero iterations and the EOF check fires immediately. If the marks file has any bytes on disk (e.g. trailing bytes from a stress-killed merge or a flushed compression header), the check throws during ATTACH or SYSTEM PREWARM MARK CACHE.

A part with zero granules has nothing to load, so this fix returns an empty marks structure without opening the file. The pre-existing file_size == 0 check is preserved with the now-redundant marks_count != 0 predicate dropped.

CIDB cross-PR evidence over 30 days for Too many marks .. text(tokenizer:

Three independent hits on three unrelated branches over ~17 hours - trunk-side issue, not caused by any open PR.

Tracked by #106621.

Changelog category (leave one):

Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fix server failing to start with Too many marks in file ...skp_idx_idx.cmrk4, marks expected 0 (bytes size 0) when a MergeTree table has a skip-index part with zero granules and a non-empty marks file on disk.

Documentation entry for user-facing changes

Documentation is written (mandatory for new features)

Version info

Merged into: 26.6.1.1035

`MergeTreeMarksLoader::loadMarksImpl` opens the marks file unconditionally and verifies that the underlying reader is at EOF after the requested number of marks has been consumed. For a part with zero granules (`marks_count == 0`) the for-loop runs 0 iterations and the EOF check fires immediately. If the marks file on disk happens to contain any bytes, the check throws `Too many marks in file <path>, marks expected 0 (bytes size 0)` during table ATTACH or `SYSTEM PREWARM MARK CACHE`, which prevents the server from starting up. This shape was observed in stress tests where a `text(tokenizer = array())` skip-index part on a deeply-mutated empty result (`all_1_7_2_8` with zero rows) ended up with a non-empty `skp_idx_idx.cmrk4` file. Independent hits on master, PR ClickHouse#103961 and PR ClickHouse#106621 within ~17 hours pointed to a trunk-side issue rather than a PR regression. Return an empty marks structure when `marks_count == 0` without opening the file. The check is moved before the existing `file_size == 0` validation so the empty-marks-count path is fully decoupled from file content. The pre-existing `file_size == 0` check is preserved with the now-redundant `marks_count != 0` predicate dropped: the new early-return makes that branch unreachable when `marks_count` is zero. Adds a regression test that creates an empty part with a `text` skip-index and exercises `SYSTEM PREWARM MARK CACHE`. Tracked by ClickHouse#106621 (replied). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

groeneai · 2026-06-07T12:01:38Z

Pre-PR validation gate

#	Question	Answer
a	Deterministic repro?	Yes. Locally: create a `MergeTree` table with `INDEX ... TYPE text(tokenizer = array()) GRANULARITY 100000000`, insert 7 batches, `OPTIMIZE FINAL`, then `ALTER TABLE ... DELETE WHERE 1` produces an `all_1_7_2_8` part with 0 rows. Adding any byte to the resulting `skp_idx_idx.cmrk4` file (or, in stress, a partial flush from a killed merge) makes `SYSTEM PREWARM MARK CACHE` throw `Too many marks in file ..., marks expected 0 (bytes size 0)` on master.
b	Root cause explained?	`MergeTreeMarksLoader::loadMarksImpl` builds a `CompressedReadBufferFromFile` over the marks file, then runs the read loop `for (size_t i = 0; i < marks_count; ++i)`. With `marks_count == 0` the loop runs 0 iterations and the post-loop `if (!reader->eof())` check fires on the first read. If the file has any bytes on disk (compression header, leftover data, partial write from a stress-killed merge), `eof()` returns false, the `Too many marks ...` exception is thrown during ATTACH / prewarm, and the table fails to load - which surfaces as `Cannot start clickhouse-server` on stress jobs.
c	Fix matches root cause?	Yes. A part with zero granules has nothing to load, so the loader returns an empty `MarksInCompressedFile` without opening the file. Decoupling the empty-marks-count path from file content is the right fix because the file-content check has nothing to validate when there are no granules.
d	Test intent preserved / new tests added?	Yes. New `04323_text_index_marks_empty_part.sql` builds the empty `all_1_7_2_8` part and exercises `SYSTEM PREWARM MARK CACHE` + `SELECT count()`. Existing marks-corruption regressions still pass: `01000_bad_size_of_marks_skip_idx`, `01640_marks_corruption_regression`, `02381_compress_marks_and_primary_key`, `02346_text_index_array_support`, `03254_prewarm_mark_cache_columns`. The pre-existing `file_size == 0` validation is preserved (with the now-redundant `marks_count != 0` predicate dropped because the early return makes that branch unreachable).
e	Both directions demonstrated?	Yes. With the fix the new test passes (output `0\n0`). Without the fix, injecting bytes into the part's `skp_idx_idx.cmrk4` produces the `Too many marks in file ..., marks expected 0 (bytes size 0)` exception in `SYSTEM PREWARM MARK CACHE` - same stack as CI.
f	Fix is general, not a narrow patch?	Yes. The fix is in `MergeTreeMarksLoader`, not at any text-index call site. It applies to ALL skip indexes (minmax, bloom, set, vector similarity, text) AND to data marks (`.cmrk2`, `.cmrk4`, `*.mrk2`). All callers funnel through `loadMarksImpl`. The same shape - reading a marks file when zero marks are expected - is wrong regardless of which file or which caller. The CI failures observed in stress are a text-index manifestation, but the contract `marks_count == 0 → return no marks` is generic.

CIDB last 30 days for Too many marks .. text(tokenizer:

pull_request_number	hits	last_seen
0 (master)	1	2026-06-05 23:57:55
103961	1	2026-06-05 13:42:29
106621	1	2026-06-06 06:40:55

Session id: cron:clickhouse-ci-task-worker:20260607-110600

groeneai · 2026-06-07T12:01:45Z

cc @CurtizJ @KochetovNicolai - could you review this? It returns early from MergeTreeMarksLoader::loadMarksImpl when marks_count == 0, fixing a stress-test Cannot start clickhouse-server failure where the marks file on disk is non-empty for a part with zero granules (Too many marks in file ..., marks expected 0 (bytes size 0)).

clickhouse-gh · 2026-06-07T12:24:43Z

Workflow [PR], commit [d550776]

Summary: ❌

Performance Comparison: Performance dashboard

job_name	test_name	status	info	comment
BuzzHouse (arm_asan_ubsan)		ERROR

AI Review

Summary

This PR makes MergeTreeMarksLoader::loadMarksImpl return an empty marks structure when marks_count is zero, avoiding mark-file reads for zero-granule MergeTree parts, and adds a focused stateless regression test that creates a zero-granule part with a non-empty skp_idx_idx.mrk4. The current test addresses the prior review concern by reproducing the non-empty mark-file shape, and I did not find a remaining correctness, compatibility, or test-evidence issue.

Final Verdict

Status: ✅ Approve

The previous .sql variant used `OPTIMIZE FINAL + ALTER DELETE WHERE 1` to produce a part with `marks_count == 0`, but `MergeTreeData::createEmptyPart` emits a zero-byte `skp_idx_idx.cmrk4` for such parts and the old `loadMarksImpl` already short-circuited that case via `file_size == 0 && marks_count != 0` (false because `marks_count == 0`). The test therefore passed both with and without the fix. This rewrite uses a `.sh` test that drops `compress_marks` to produce uncompressed `mrk4` files (so the size validation at the top of `loadMarksImpl` is the trigger), then deterministically: 1. Builds a part with `marks_count == 0` (`OPTIMIZE FINAL` then `ALTER ... DELETE WHERE 1`). 2. `DETACH TABLE`, appends one byte to `skp_idx_idx.mrk4`, removes `checksums.txt` so re-attach recomputes them from disk. 3. `ATTACH TABLE`. On master HEAD (no fix), step 3 throws `Bad size of marks file ...skp_idx_idx.mrk4: 1, must be: 0` (`CORRUPTED_DATA`, code 246). With the fix, `loadMarksImpl` returns immediately on `marks_count == 0` and `ATTACH TABLE` succeeds. The compressed-marks (`cmrk4`) variant from the original CIDB report reaches the same fix via the same early-return; we exercise the uncompressed path here because it is reproducible deterministically with a single byte append (the compressed path needs a synthetic valid LZ4 frame, which is a strictly weaker test of the same code). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

groeneai · 2026-06-07T20:16:00Z

Pre-PR validation gate

#	Question	Answer
a	Deterministic repro?	Yes. The new `.sh` test (commit `0546e1b5086a`) builds a part with `marks_count == 0`, appends one byte to `skp_idx_idx.mrk4`, drops `checksums.txt`, then `ATTACH TABLE`. The bug fires every time on master HEAD.
b	Root cause explained?	`MergeTreeMarksLoader::loadMarksImpl` opens the marks file unconditionally. For a `marks_count == 0` part, the for-loop runs zero iterations and either the size check (uncompressed) or the post-loop `eof()` check (compressed) fires whenever the on-disk file has any non-zero size. Stress kills can leave such a state on disk; CI hit it on `cmrk4` (`Too many marks in file ...`) and our reproducer hits the same code path on the uncompressed `mrk4` (`Bad size of marks file ..., 1, must be: 0`).
c	Fix matches root cause?	Yes. The fix returns an empty `MarksInCompressedFile` immediately on `marks_count == 0`, before any file I/O. Both compressed and uncompressed mark file paths are protected by the same early-return.
d	Test intent preserved / new tests added?	Test rewritten to actually demonstrate the regression. Previous `.sql` variant produced a part with a zero-byte `cmrk4`, which the old code already tolerated (`file_size == 0 && marks_count != 0` is false), so the test passed on both master and the fix. The new `.sh` test produces the exact `marks_count == 0 + non-empty mark file` shape the fix protects against.
e	Both directions demonstrated?	Yes. Verified locally: master HEAD without fix → `Code: 246. DB::Exception: Bad size of marks file '...skp_idx_idx.mrk4': 1, must be: 0. (CORRUPTED_DATA)` master HEAD + fix → test passes, 5/5 runs.
f	Fix is general, not a narrow patch?	Yes. The early return on `marks_count == 0` covers both uncompressed (`mrk4`, fires `Bad size of marks file`) and compressed (`cmrk4`, fires `Too many marks in file`) variants in one place. The pre-existing `file_size == 0 && marks_count != 0` predicate is now redundant and simplified to `file_size == 0`.

The compressed-marks variant from the original CIDB report reaches the same fix via the same early-return; we exercise the uncompressed path in the test because it is reproducible deterministically with a single byte append (the compressed path would need a synthetic valid LZ4 frame, which is a strictly weaker test of the same code).

Session id: cron:clickhouse-ci-task-worker:20260607-194300

The previous version of `04323_text_index_marks_empty_part.sh` worked by detaching the table, appending a byte to `skp_idx_idx.mrk4`, removing `checksums.txt`, and re-attaching. On the Fast test runner that path emitted a Warning to stderr (`Checksums for part ... not found. Will calculate them from data on disk.`), and the part loader also failed an unrelated `columns_substreams.txt` precondition before reaching the marks loader at all, so the test no longer exercised the fix it was supposed to demonstrate. The simpler path is enough. After `OPTIMIZE FINAL` and `ALTER ... DELETE WHERE 1` the active part already has `marks_count == 0` and a zero-byte `data.cmrk4` (or `data.mrk4` with `compress_marks = 0`). Without the `marks_count == 0` early-return in `loadMarksImpl` the zero-byte file fails the `file_size == 0` validation immediately on `SYSTEM PREWARM MARK CACHE` with `Empty marks file ...: 0, must be: 0` (`CORRUPTED_DATA`, code 246). With the fix the early-return skips that validation and prewarm succeeds. Verified locally in both directions: - without the `marks_count == 0` short-circuit reverted from `MergeTreeMarksLoader::loadMarksImpl`, `SYSTEM PREWARM MARK CACHE` throws `Empty marks file '.../data.cmrk4': 0, must be: 0` - with the fix restored, the test passes (50/50 with `--no-random-settings`) The detach/append/checksum dance and the verbose block comment are gone; the same comment about why the test exists belongs in the commit message, not in the file. Addresses clickhouse-gh[bot]'s review concern that the prior shape did not actually exercise the regression. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

groeneai · 2026-06-07T21:27:07Z

Pre-PR validation gate (commit `deca0bdc7678`)

#	Question	Answer
a	Deterministic repro?	Yes. The local repro is just `CREATE … TYPE text(tokenizer = array()) GRANULARITY 100000000 ENGINE = MergeTree ORDER BY tuple() SETTINGS prewarm_mark_cache = true`, two tiny `INSERT`s, `OPTIMIZE FINAL`, `ALTER … DELETE WHERE 1 SETTINGS mutations_sync = 2`, then `SYSTEM DROP MARK CACHE; SYSTEM PREWARM MARK CACHE`. With the `marks_count == 0` early-return reverted out of `MergeTreeMarksLoader::loadMarksImpl`, the prewarm step throws `DB::Exception: Empty marks file '.../data.cmrk4': 0, must be: 0. (CORRUPTED_DATA)` (code 246) on every run. Direct rebuild + restart, no randomization.
b	Root cause explained?	Yes. After `ALTER … DELETE WHERE 1` the active part is the empty mutated part with `marks_count == 0` and a zero-byte `data.cmrk4` (or `data.mrk4` with `compress_marks = 0`). The pre-fix `loadMarksImpl` opens the file unconditionally and runs the `file_size == 0` validation, which throws `CORRUPTED_DATA` (the same root cause as the original `Too many marks in file …cmrk4` shape from CI — same code path, just a different post-EOF check on top). The fix returns early on `marks_count == 0` before either validation runs.
c	Fix matches root cause?	Yes. Commit `873efbe89db4` short-circuits `loadMarksImpl` on `marks_count == 0` before any file is opened. That is exactly what makes the `data.cmrk4` zero-byte case stop throwing. No bounds widening, no `no-random-*` blanket.
d	Test intent preserved / new tests added?	Yes. The previous shape of `04323_text_index_marks_empty_part` did not actually exercise the fix (clickhouse-gh[bot] flagged this in 4547429947): the `ALTER … DELETE WHERE 1` empty-part path produced a zero-byte mark file that the pre-existing `file_size == 0` short-circuit already tolerated for the case the prior test set up, AND the post-detach `ATTACH` was failing on an unrelated `columns_substreams.txt` precondition before ever reaching the marks loader (and emitting a `Checksums for part ... not found` Warning that broke Fast test). The new shape removes the detach/append/checksum dance and exercises `loadMarksImpl` directly via `SYSTEM PREWARM MARK CACHE`. The test now both demonstrates the regression on master HEAD without the fix and silently passes with the fix.
e	Both directions demonstrated?	Yes. Locally rebuilt with `873efbe89db4` reverted out of `MergeTreeMarksLoader.cpp`: `SYSTEM PREWARM MARK CACHE t_text_idx_empty` throws `CORRUPTED_DATA: Empty marks file '.../data.cmrk4': 0, must be: 0`. Restored the fix and rebuilt: `clickhouse-test --no-random-settings --test-runs 50` is 50/50 PASS, no stderr emitted, reference matches `0\t0\n0\n0`.
f	Fix is general, not a narrow patch?	Yes. `loadMarksImpl` is the single shared code path used by every mark-loader caller (table prewarm, ATTACH-time index marks, IndexMarkCache prewarm, async-load future paths) — both compressed (`.cmrk4`) and uncompressed (`.mrk4`) variants. The early-return is independent of `mark_type.compressed` / `mark_type.adaptive`, so it covers the original CI shape (`Too many marks in file …cmrk4` from `CompressedReadBufferFromFile::eof()` after the loop) and the trivial empty-file shape (`Empty marks file …` from the `file_size == 0` check) in one place. No sibling code paths to fix. The bad state is legitimately possible — `marks_count == 0` is a normal post-`ALTER DELETE WHERE 1` and post-merge empty-part state — so an early return is correct, not a defensive guard against an upstream bug.

Session id: cron:clickhouse-ci-task-worker:20260607-210400

The previous simplification (commit deca0bd) reduced 04323 to a plain SYSTEM PREWARM MARK CACHE on a mutated empty part. Reviewer clickhouse-gh[bot] correctly pointed out this does not prove the fix: In the PR base (da698ac) MergeTreeMarksLoader::loadMarksImpl guards the throw with `if (file_size == 0 && marks_count != 0)` -- for a part with `marks_count == 0` and a zero-byte mark file the predicate is false and the loader silently returns. Any test that only creates the empty-part state therefore passes both with and without this PR. The CI failure shape requires `marks_count == 0` AND a non-empty mark file on disk. This commit restores the deterministic byte-append fixture (the shape from the earlier 0546e1b test) but addresses the Fast-test stderr-empty regression that broke that earlier attempt. The ATTACH after the manual mark-file mutation emits a Warning to stderr (`Checksums for part ... not found. Will calculate them from data on disk.`); we suppress it with --send_logs_level=fatal, matching the precedent in 04230_iceberg_optimize_metadata_not_initialized_104711.sh. Verification on the actual PR base da698ac: Without fix: ATTACH throws `Bad size of marks file '...mrk4': 1, must be: 0` (CORRUPTED_DATA, code 246) -- test FAILS. With fix: `loadMarksImpl` early-returns on `marks_count == 0`, ATTACH succeeds, prewarm + queries return 0 -- 10/10 PASS under random settings. The fix in this PR (in `MergeTreeMarksLoader::loadMarksImpl`) is unchanged. Related: ClickHouse#106675 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

groeneai · 2026-06-08T04:33:18Z

Pre-PR validation gate

#	Question	Answer
a	Deterministic repro?	Yes. The new `.sh` test deterministically produces a part with `marks_count == 0` + non-empty `skp_idx_idx.mrk4` via `OPTIMIZE FINAL` + `ALTER ... DELETE WHERE 1` + `printf '\x00' >> skp_idx_idx.mrk4`. On PR base `da698ac3be4f71b67bdc3eb3c4e2c393700f76f3` the subsequent `ATTACH TABLE` throws `CORRUPTED_DATA` (246) on every run.
b	Root cause explained?	`MergeTreeMarksLoader::loadMarksImpl` opened the mark file unconditionally on the prewarm path. For `marks_count == 0`, the validation `if (!compressed && expected_uncompressed_size != file_size)` fires whenever `file_size != 0`, throwing `Bad size of marks file '...': N, must be: 0`. The bug shape is `marks_count == 0` AND non-empty mark file on disk; the previous PR-base predicate `if (file_size == 0 && marks_count != 0)` silently passed `marks_count == 0` + zero-byte files but did not protect this case.
c	Fix matches root cause?	Yes. `loadMarksImpl` early-returns an empty `MarksInCompressedFile` when `marks_count == 0` (before any file I/O). The pre-existing `file_size == 0` check is preserved with the now-redundant `marks_count != 0` predicate dropped: the new early-return makes that branch unreachable when `marks_count` is zero.
d	Test intent preserved / new tests added?	New regression test added: `tests/queries/0_stateless/04323_text_index_marks_empty_part.sh`. Drives exactly the `marks_count == 0` + non-empty mark file shape via deterministic byte-append. The Warning suppression is `--send_logs_level=fatal` only on the ATTACH client invocation that is allowed to emit a harmless checksum-recompute Warning; all other client invocations still surface stderr normally.
e	Both directions demonstrated?	Yes, on PR base `da698ac3be4f71b67bdc3eb3c4e2c393700f76f3`. Without fix: `ATTACH TABLE` throws `Bad size of marks file '...skp_idx_idx.mrk4': 1, must be: 0` (`CORRUPTED_DATA`, 246), test FAILS. With fix: 10/10 PASS via `tests/clickhouse-test --test-runs 10 04323_text_index_marks_empty_part` under random settings.
f	Fix is general, not a narrow patch?	Yes. The early-return in `loadMarksImpl` is the single chokepoint for both the compressed (`.cmrk4`, original CIDB stress hit) and uncompressed (`.mrk4`, this regression test) paths -- both use the same loader. No symmetric callsite carries the same logic. The fix addresses the root cause (loader opens the file on a `marks_count == 0` part) at the source, not at the throw site.

Session id: cron:clickhouse-ci-task-worker:20260608-041400

groeneai · 2026-06-08T08:47:32Z

CI Status — covered SHA `c5a9dfad452`

CI fully finished. All failures are pre-existing chronic master bugs unrelated to this PR's diff (src/Storages/MergeTree/MergeTreeMarksLoader.cpp early-return + the 04323_text_index_marks_empty_part.sh regression test).

Check	Test	Disposition
`Stateless tests (amd_debug, parallel)`	`Logical error: Virtual row boundary violated in MergingSortedAlgorithm` (STID `2651-3359`)	chronic master regression, NOT PR-caused. Cross-PR query (30d): hits master + 25+ unrelated PRs (#105386, #106215, #104965, #67954, #79393, #99675, etc.). Tracked in umbrella task with fix PR #106664 in flight (vdimir territory, on the heap-position correctness path). The merging path is unrelated to `MergeTreeMarksLoader::loadMarksImpl`.
`Stateless tests (amd_debug, parallel)`	`Server died`	cascade of the above — debug assertion in `MergingSortedAlgorithm::consume` aborts the server, which terminates whatever test was running.
`Stateless tests (amd_debug, parallel)`	`02346_text_index_replacingmergetree1` ERROR	collateral damage — happened to be the test in flight when the server aborted from the STID 2651-3359 assertion. Cross-PR check: only 1 prior hit (#103706 on 2026-05-20) — not a chronic flake of this test, but a victim of the upstream crash.

PR diff only changes MergeTreeMarksLoader.cpp + adds a regression test. None of these touch the MergingSortedAlgorithm / virtual-row machinery.

Session: cron:our-pr-ci-monitor:20260608-083000

clickhouse-gh · 2026-06-18T14:53:45Z

LLVM Coverage Report

Metric	Baseline	Current	Δ
Lines	85.20%	85.20%	+0.00%
Functions	92.30%	92.30%	+0.00%
Branches	77.50%	77.50%	+0.00%

Changed lines: Changed C/C++ lines covered by tests: 11/13 (84.62%) | Lost baseline coverage: none · Uncovered code

Full report · Diff report

groeneai · 2026-06-19T12:43:42Z

groeneai mentioned this pull request Jun 7, 2026

Fix Memory table abort on ALTER commands with no per-row data effect (STID 2380-3043) #106621

Merged

1 task

nikitamikhaylov added the can be tested Allows running workflows for external contributors label Jun 7, 2026

clickhouse-gh Bot added the pr-bugfix Pull request with bugfix, not backported by default label Jun 7, 2026

clickhouse-gh Bot reviewed Jun 7, 2026

View reviewed changes

Comment thread tests/queries/0_stateless/04323_text_index_marks_empty_part.sql Outdated

groeneai mentioned this pull request Jun 7, 2026

Allow INSERT into regular views #102866

Open

1 task

This was referenced Jun 8, 2026

Skip writing all-default columns during MergeTree INSERT #98472

Open

fix(docs): readWKTMultiLineString example uses wrong function name #106173

Closed

hanfei1991 self-assigned this Jun 11, 2026

hanfei1991 approved these changes Jun 18, 2026

View reviewed changes

Merge branch 'master' into groeneai/fix-text-index-marks-corruption

d550776

hanfei1991 added this pull request to the merge queue Jun 19, 2026

Merged via the queue into ClickHouse:master with commit 168b5ad Jun 19, 2026
164 of 166 checks passed

robot-clickhouse-ci-1 added the pr-synced-to-cloud The PR is synced to the cloud repo label Jun 19, 2026

groeneai mentioned this pull request Jun 20, 2026

Throw a clear error when a marks file listed in checksums is missing on disk #107150

Open

Sunbelt Computer Software

PL/B Language Development and Support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Skip mark file read for parts with zero granules#106675

Skip mark file read for parts with zero granules#106675
hanfei1991 merged 5 commits into
ClickHouse:masterfrom
groeneai:groeneai/fix-text-index-marks-corruption

groeneai commented Jun 7, 2026 •

edited by robot-clickhouse

Loading

Uh oh!

groeneai commented Jun 7, 2026

Uh oh!

groeneai commented Jun 7, 2026

Uh oh!

clickhouse-gh Bot commented Jun 7, 2026 •

edited

Loading

Uh oh!

Uh oh!

groeneai commented Jun 7, 2026

Uh oh!

groeneai commented Jun 7, 2026

Uh oh!

groeneai commented Jun 8, 2026

Uh oh!

groeneai commented Jun 8, 2026

Uh oh!

clickhouse-gh Bot commented Jun 18, 2026

Uh oh!

groeneai commented Jun 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Conversation

groeneai commented Jun 7, 2026 • edited by robot-clickhouse Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog category (leave one):

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Documentation entry for user-facing changes

Version info

Uh oh!

groeneai commented Jun 7, 2026

Pre-PR validation gate

Uh oh!

groeneai commented Jun 7, 2026

Uh oh!

clickhouse-gh Bot commented Jun 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

AI Review

Summary

Final Verdict

Uh oh!

Uh oh!

groeneai commented Jun 7, 2026

Pre-PR validation gate

Uh oh!

groeneai commented Jun 7, 2026

Pre-PR validation gate (commit deca0bdc7678)

Uh oh!

groeneai commented Jun 8, 2026

Pre-PR validation gate

Uh oh!

groeneai commented Jun 8, 2026

CI Status — covered SHA c5a9dfad452

Uh oh!

clickhouse-gh Bot commented Jun 18, 2026

LLVM Coverage Report

Uh oh!

groeneai commented Jun 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

groeneai commented Jun 7, 2026 •

edited by robot-clickhouse

Loading

clickhouse-gh Bot commented Jun 7, 2026 •

edited

Loading

Pre-PR validation gate (commit `deca0bdc7678`)

CI Status — covered SHA `c5a9dfad452`