[strtgbb]

Changelog category (leave one):

• Critical Bug Fix (crash, data loss, RBAC)

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

Bump brotli from v1.0.9 to v1.0.10; fix CVE-2026-111497

Description

• Bump brotli from v1.0.9 to v1.0.10 (fix CVE-2026-111497), with a regression gtest src/IO/tests/gtest_brotli_decoder.cpp. Taken from 23.8 Stable: Bump brotli from v1.0.9 to v1.0.10 #2690.

CI fixes for releases/23.8.16:

• Update runner labels; read CI secrets from env instead of SSM; update artifact actions.
• Use the clickhouse/minio-minio mirror image for integration tests. minio/minio was deleted from Docker Hub, so every with_minio=True test failed in cluster.start() with pull access denied for minio/minio. The mirror (upstream Mirror the MinIO integration-test images into the clickhouse/ namespace ClickHouse/ClickHouse#119999) has no RELEASE.2021-09-23T04-46-24Z tag, so minio is bumped to RELEASE.2024-07-31T05-46-26Z, same as releases/24.8.14.
• Take the test_storage_delta fix from upstream Upgrade MinIO to support accepting non signed requests ClickHouse/ClickHouse#55245 (the 2021 → 2023 minio upgrade): newer minio does not match a list_objects prefix with a leading slash.
• Take the stateless-test minio/mc binaries from clickhouse/minio-minio:RELEASE.2024-07-31T05-46-26Z instead of dl.min.io, which now returns 410 Gone, so the image could no longer be rebuilt. Same as upstream Update minio in stateless tests ClickHouse/ClickHouse#67975 (stateless tests on 2024 minio), it also takes the renamed mc admin policy attach / mc anonymous set commands in setup_minio.sh and the S3ObjectStorage::listObjects fix that skips a "/" prefix.

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Performance tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All with Aarch64
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[altinity-robot]

This is an automated comment for commit 581c21f with description of existing statuses. It's updated for the latest CI running

❌ Click here to open a full report in a separate page

Successful checks

Check name	Description	Status
ClickHouse build check	Builds ClickHouse in various configurations for use in further steps. You have to fix the builds that fail. Build logs often has enough information to fix the error, but you might have to reproduce the failure locally. The cmake options can be found in the build log, grepping for cmake. Use these options and follow the general build process	✅ success
Compatibility check	Checks that clickhouse binary runs on distributions with old libc versions. If it fails, ask a maintainer for help	✅ success
Docker image for servers	The check to build and optionally push the mentioned image to docker hub	✅ success
Install packages	Checks that the built packages are installable in a clear environment	✅ success
Integration tests	The integration tests report. In parenthesis the package type is given, and in square brackets are the optional part/total tests	✅ success
Mergeable Check	Checks if all other necessary checks are successful	✅ success
Push to Dockerhub	The check for building and pushing the CI related docker images to docker hub	✅ success
Ready for release	There's no description for the check yet, please add it to tests/ci/ci_config.py:CHECK_DESCRIPTIONS	✅ success
Stateful tests	Runs stateful functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	✅ success
Stateless tests	Runs stateless functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	✅ success

Check name	Description	Status
CI running	A meta-check that indicates the running CI. Normally, it's in success or pending state. The failed status indicates some problems with the PR	⏳ pending
Stress test	Runs stateless functional tests concurrently from several clients to detect concurrency-related errors	❌ failure

[zvonand]

@blau-ai

[blau-ai]

CI triage for 581c21f

Summary: 2 failing checks. Neither is caused by a code change in this PR.

Check	Verdict
DCO	Process issue in this PR: the head commit has no sign-off. Simple fix, see below.
Stress test (asan)	Known false assertion in the 23.8 filesystem cache. Upstream already removed it, but it was never backported to 23.8. Not caused by this PR's code. Hit twice on this branch.

Several regression jobs (Alter (attach), S3 (aws_s3), S3 (minio), Common (aggregate_functions)) are still running, so this triage does not cover them. All other finished checks pass: builds, stateless/stateful/integration, the other 4 stress runs, compatibility and docker.

---

1. DCO: failure caused by this PR (sign-off only)

:red_circle: 581c21f  Remove bad test (3)  Sign-off not found

The other 24 commits are skipped as "sign-off not required for members". The head commit is the cherry-pick of upstream 2c86d7db ("Remove bad test (3)"). Its author is Alexey Milovidov, so the members exemption doesn't apply, and the cherry-pick added no Signed-off-by.

Fix (any one of these):

• An org admin overrides DCO for this PR. For a cherry-picked upstream commit, this is the usual route.
• Add a DCO remediation commit, which needs no force-push. See cncf/dco2 "individual remediation".
• Amend with git commit --amend -s and force-push. I can't do this one (no force-push), and it would also restart CI.

For future cherry-picks, use git cherry-pick -x -s.

2. Stress test (asan): not caused by this PR (stale assertion in fs cache)

Report · fatal_messages · gdb.log

<Fatal> : Logical error: 'inserted'.
<Fatal> Application: Child process was terminated by signal 6.
Thread 400 "LoadMarksThread" received signal SIGABRT
#3  DB::abortOnFailedAssertion   src/Common/Exception.cpp:50
#4  DB::CleanupQueue::add        src/Interpreters/Cache/Metadata.cpp:376
#5  DB::LockedKey::~LockedKey    src/Interpreters/Cache/Metadata.cpp:677
#11 DB::FileSegment::complete    src/Interpreters/Cache/FileSegment.cpp:718
#17 DB::CachedOnDiskReadBufferFromFile::~CachedOnDiskReadBufferFromFile

The other two red rows in that report are effects of this one crash, not separate failures:

• "Hung check failed": the hung check got only Connection refused because the server had already died.
• "Fatal message in log": the same Logical error: 'inserted' line.

Why it's not this PR's code:

• The PR touches nothing under src/Interpreters/Cache/ or src/Disks/IO/. The only server-side change is the path != "/" prefix guard in S3ObjectStorage::listObjects, which is not on this stack. The rest is CI/docker/tests plus the brotli bump and its gtest.
• The assertion is chassert(inserted) in CleanupQueue::add. Upstream deleted it in Sept 2023 as "Remove incorrect assertion" (kssenii, commit d368dda185c, part of Add assertion ClickHouse/ClickHouse#54985, merged into master after the 23.8 branch point). It was never backported, so releases/23.8.16 still has it. chassert only aborts in debug/sanitizer builds, so release binaries are not affected.
• It also failed the same way on this branch's earlier run on 296f2e9 (00:10:34 ... Logical error: 'inserted'). So it is reproducible on 23.8 stress/asan, not a one-off.

Caveat: releases/23.8.16 has no stress run of its own to compare against. Earlier ASan stress runs on this branch also used the new CI images, so I can't show it failing before this PR. The likely reason it surfaces now is that the refreshed stress environment (minio mirror, new images) exercises the S3 + filesystem-cache path more. That is a guess. The code-level evidence above is solid: the asserted invariant is one upstream itself judged incorrect.

Suggested fix: backport the one-line removal of chassert(inserted) (plus its comment) from d368dda185c into src/Interpreters/Cache/Metadata.cpp. You could add it to this PR, or do it in a small separate 23.8 PR. The code right after the assertion already handles !inserted correctly (if (inserted) { ... }). If you prefer not to change server code in this infra PR, this failure is safe to treat as known/pre-existing for 23.8.

---

I didn't push anything. Just ask if you want me to add the assertion-removal backport to this branch (or open it as a separate blau/* PR). Either way, CI on that commit would confirm the fix.