Antalya 25.8 Backport of #1416 - MergeTreeData: force Wide part format when the table has deprecated Object columns

[mkmkme]

MergeTreeData: force Wide part format when the table has deprecated Object columns

Same as #1416, but for Antalya 25.8

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful 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)
• 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 [3f6fe24]

[mkmkme]

@blau-ai

[blau-ai]

CI triage — 5 red checks: 0 PR-caused, 4 pre-existing/flaky/infra, 1 aggregate gate

This backport is tiny and low-risk: it only forces Wide part format when a table has deprecated Object columns (hasDynamicSubcolumnsDeprecated(...) in choosePartFormat) plus a new stateless test 03779_object_in_compact_mergetree_parts. I checked every failing job's logs — none of the failures involve deprecated Object columns or the changed code path, and the same source compiled cleanly in the debug and binary configs (their binaries were downloaded and run by the stress/stateless jobs). Recent antalya-25.8 base-branch CI is itself red on the same suites, consistent with pre-existing infra/suite flakiness rather than a regression from this PR.

Per-check breakdown

1. Build (amd_release) — infra/timeout, not PR-caused
Job got terminated with an error, exit code [-15] (SIGTERM) after 2h2m34s. The identical source built fine for amd_debug and amd_binary (the stress and stateless jobs downloaded and ran those packages), so this is not a compile error from the diff — it's a runner timeout/reclaim of the release build.
→ Just re-run the build job.

2. Stress test (amd_debug) — "Cannot start clickhouse-server", pre-existing (tiered-storage engine)
Server fails during startup metadata load:

Application: Caught exception while loading metadata: Code: 722 ... Code: 695 ...
Load job 'load table test_3.test_tiered_watermark' failed: Code: 60.
Table default.test_tiered_watermark_before does not exist.
  ... ATTACH TABLE test_3.test_tiered_watermark ... ENGINE = Hybrid(
      remote(..., 'test_tiered_watermark_after'), date >= '2025-09-01',
      remote(..., currentDatabase(), 'test_tiered_watermark_before'), date < '2025-09-01')

This is the Antalya Hybrid / tiered-storage engine, where currentDatabase() resolves to default instead of test_3 during ATTACH-on-startup. Nothing to do with MergeTree part format.
→ Pre-existing / infra; safe to re-run.

3. Stateless tests (amd_binary, ParallelReplicas, s3 storage, parallel) — flaky, not PR-caused
The GitHub Actions job itself is green (✓); the check is red only because the S3 report counts Failed: 1. The single FAIL is:

01710_projection_additional_filters:  [ FAIL ] 0.95 sec.   (1 error in Process-6)

That's a projections + additional-filters test — no deprecated Object columns. This PR's own new test 03779 was skipped in this ParallelReplicas/s3 config (it only appears in the job's changed_files list, not as a test result). Known-flaky under ParallelReplicas.
→ Safe to re-run.

4. Regression x86 swarms / RegressionTestsRelease / Swarms — flaky suite, not PR-caused
1 of 1520 scenarios failed (523 retries, 84 failed):

/swarms/feature/swarm joins/join clause/... iceberg(...) with s3(...) ... RIGHT SEMI JOIN
AssertionError
Code: 170. DB::Exception: Bad get: has Int64, requested Decimal64:
  While executing ReadFromObjectStorage. (BAD_GET)

An Iceberg×S3 parquet type-coercion mismatch (Int64 vs Decimal64) in the swarms/iceberg regression suite — unrelated to MergeTree part format.
→ Pre-existing / flaky; safe to re-run.

5. PR — aggregate gate
Red only because of the above; not an independent failure.

Bottom line

No code fix is needed for this PR. Recommend re-running the failed jobs (Build (amd_release), Stress test (amd_debug), the ParallelReplicas stateless shard, and Swarms). If the release-build timeout recurs, that's a CI-capacity issue for the infra team, not this change.

_{🤖 Automated CI triage by @blau-ai — evidence from run 30079129933. I can't build/run ClickHouse locally, so this is log-based static analysis; correctness of the change is validated by a green re-run.}