Fix SettingsChangesHistory.cpp

[ianton-ru]

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

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

Fix Settings Changes History.

Documentation entry for user-facing changes

...

CI/CD Options

Exclude tests:

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

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• CAS (content-addressed storage; Antalya only)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• OAuth (5m)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [7515aa5]

[ianton-ru]

@blau-ai

[blau-ai]

CI triage for #2293 — Fix SettingsChangesHistory.cpp

Verdict: 4 red checks, 0 caused by this PR. All are infra/flaky or environment (runner) failures, isolated to individual shards. This PR only edits src/Core/SettingsChangesHistory.cpp (pure compatibility-metadata: it moves 8 Altinity settings out of the upstream 26.6 bucket into a new 26.3.1.20001.altinityantalya version bucket). That code path cannot affect S3 storage, integration containers, or query-pipeline width. Decisive cross-check: if a settings-history edit were malformed it would break the startup sanity-check and every shard would fail — instead all builds, Fast test, SQLLogic, both distributed-plan stateless shards, cas-s3 shard 1/2, and 7/8 integration shards are green. So it's safe to re-run the red jobs; no fix is needed on the PR.

---

1. Integration tests (amd_asan_ubsan, db disk, old analyzer, 4/8) — 12/1089 · infra, not PR-related
All 12 failures are the same test file, test_storage_iceberg_with_spark/test_schema_inference.py::test_schema_inference[...] (parametrized s3/azure × 1/2 × True/False). Every one dies talking to the shard's storage container:

Code: 210. DB::NetException: Connection refused (172.16.1.12:9000). (NETWORK_ERROR)
Code: 32.  DB::Exception: Attempt to read after eof: while receiving packet from 172.16.1.12:9000 (ATTEMPT_TO_READ_AFTER_EOF)

The MinIO/storage container 172.16.1.12:9000 was down/unreachable for that shard, so the whole iceberg test file's parametrizations failed together. The other 7 integration shards passed with 0 failures. → Re-run.

2. Stateless tests (amd_asan_ubsan, cas s3 storage, parallel, 2/2) — 25 failed + 7 broken · environment (runner), not PR-related
Sampled failures (01883_with_grouping_sets, 03402_fix_pipe_resize_with_two_level_hash) are EXPLAIN PIPELINE reference mismatches where the pipeline rendered fewer parallel streams than the reference (MergingSortedTransform 8 → 1 vs actual 5 → 1; ExpressionTransform × 8 vs × 4). Pipeline width tracks the runner's available cores/load, so a CPU-starved shard renders fewer lanes — a well-known environment-dependent class, plus some CAS-S3 connection noise. Companion shard 1/2 passed with 0 failures. → Re-run (ideally on a less loaded runner).

3. Stateless tests (amd_binary, cas s3 storage, parallel) — 2 failed · flaky, not PR-related (non-blocking)
Both 02354_read_in_order_prewhere and 01171_mv_select_insert_isolation_long are CI-labeled flaky and auto-reran green (6/6 and 1/1). Cause is a transient S3 write to the CAS backend:

WriteBufferFromS3: S3Exception ... e.code() = 111, Connection refused ... bucket test, key cas_s3/...

This suite carries do_not_block_pipeline_on_failure: true. → No action (self-recovered).

4. Regression release swarms — 31/1521 scenarios errored · separate regression workflow, not PR-related
This is the RegressionTestsRelease / Swarms suite (object-storage swarm scenarios), reported separately at its own .../swarms/report.html, not in the PR praktika report. Nothing in a settings-history metadata edit touches swarm/object-storage behavior, and the sibling regression suites (iceberg, parquet, oauth, s3_export) all passed. Treat as pre-existing/infra flakiness in that suite. → Re-run; if it persists on the base branch it's a known-flaky suite, not this PR.

---

PR health check: The change is a clean, correct fork-hygiene fix — Altinity-specific settings belong under an *.altinityantalya version bucket, not upstream's 26.6, so compatibility resolution and future upstream merges behave. It builds on all targets, Fast test is green, and the settings-history startup check passed everywhere (servers started across all shards). Once the four flaky/infra jobs are re-run, this should go green. No code change required from my side; happy to re-check after a re-run if you'd like.

[ianton-ru]

Add fix for allow_experimental_database_s3_tables - this setting was in incorrect section in antalya-26.3

[zvonand]

@blau-ai

[blau-ai]

CI triage — all red checks are infra/flaky/pre-existing, 0 caused by this PR

This PR touches only src/Core/SettingsChangesHistory.cpp — a pure metadata change that relocates the Antalya-specific settings (object_storage_cluster_join_mode, export_merge_tree_*, allow_experimental_database_s3_tables) out of the upstream 26.6 block into a dedicated 26.3.1.20001.altinityantalya block. It changes no runtime code path. The proof it's sound is already in this same CI run: all builds passed, and the clean stateless configs are fully green — Stateless (amd_debug, parallel) 11024 passed / 0 failed, Stateless (amd_binary, cas s3 storage, parallel) 11016 passed / 0 failed. So the server starts, the settings history parses, and nothing regressed. The failures below are all environmental.

Failing check	What actually failed	Verdict
Integration (targeted) — 12/12	all 12 are test_storage_iceberg_with_spark::test_schema_inference[*]	infra
Integration 4/8 — 12/1089	same iceberg_with_spark::test_schema_inference	infra
Integration 5/8, 8/8	"Test execution was interrupted (exit status: 2)"	infra
Integration 7/8	"Failed to pre-pull Docker images needed by the test batch"	infra
Regression s3_export_part	only the "during minio interruption" chaos cases	infra/flaky
Stateless (cas s3, 2/2) — 21 failed	~12 unrelated tests (explains, arrays, JSON, UDF masking, keeper map, cas attach)	flaky/config
Stateless (cas s3, 1/2) / (distributed plan, 2/2)	0 failed, only Broken: 9 / Broken: 6 (harness)	infra
Stateless (amd_binary, cas storage) — 1 failed	01164_detach_attach_partition_race	flaky (race test)
Unit tests (asan_ubsan) / (…, function_prop_fuzzer)	praktika report = pass (14422 & 1 passed, 0 fail); only the GH-Actions wrapper row is red	spurious/infra

Decisive evidence

• Integration tests — every failing integration case is the same test, test_storage_iceberg_with_spark/test_schema_inference.py::test_schema_inference (all parametrizations: azure/local/s3 × 1/2 × True/False). Its root cause is a broken Spark environment, not ClickHouse:

  java.lang.ClassNotFoundException: org.apache.sedona.spark.SedonaSparkSessionExtension
  WARNING : Failed connecting to Zookeeper within the connection retry policy
  DB::NetException: Connection refused
  

  Shards 5/7/8 never even ran (interrupted, exit status 2 / Failed to pre-pull Docker images). This is runner/image infra, independent of the diff.

• Regression s3_export_part — the only failing scenarios are under export part/concurrent alter/during minio interruption:

  ✘ [ Fail ] .../during minio interruption/example=fetch partition — MinIO health check failed
  ✘ [ Fail ] .../during minio interruption/example=create partitions — AssertionError
  ✘ [ Fail ] .../during minio interruption/example=drop table — AssertionError
  

  These deliberately kill MinIO mid-test; "MinIO health check failed" is the harness's own flakiness, not a settings change.

• Stateless cas s3 storage — the 21 failures are a scattershot of totally unrelated tests (02377_optimize_sorting_by_input_stream_properties_explain, 03216_arrayWithConstant_limits, 04101_json_skip_regexp_parentheses_in_type_hint, 03792_udf_masking_sensitive_data, 02703_keeper_map_concurrent_create_drop, 05025_cas_attach_partition_cross_disk, …). None are settings-related, and the non-CAS binary/debug configs pass 100%. The CAS-S3 test config is a known-unstable area currently under active investigation on sibling PRs (Enable cas s3 stress #2292 "Enable cas s3 stress", CAS-S3 GC interval 60s #2296/DO NOT MERGE: CAS-S3 test GC disabled (CI experiment) #2297 "CAS-S3 test GC" experiments).

Bottom line: nothing here needs a code fix in this PR. The change is correct and self-consistent. Recommended actions:

1. Re-run the integration matrix and s3_export_part — the Spark/ZK/MinIO/Docker infra failures should clear on a healthy runner.
2. Treat Stateless (cas s3 storage) and 01164_detach_attach_partition_race as the known-flaky CAS-S3 instability being chased in Enable cas s3 stress #2292/CAS-S3 GC interval 60s #2296/DO NOT MERGE: CAS-S3 test GC disabled (CI experiment) #2297 — not a blocker for a settings-history-only change.
3. The red Unit tests rows are a GH-Actions wrapper artifact; the praktika reports for both are green.

One optional, non-CI nit to double-check while you're here: this is the antalya-26.6 branch (release string 26.6.x.20001.altinityantalya), but the new block is keyed 26.3.1.20001.altinityantalya. If these settings first shipped in the 26.3 Antalya line that's exactly right; just confirm the version key matches where each setting was actually introduced so compatibility= resolves them correctly.