Fix typo in complex schema evolution

[scanhex12]

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 typo in complex schema evolution

Version info

• Merged into: 26.7.1.1378 (included in 26.7 and later)
• Backported to: 26.7.2.48, 26.6.2.105, 26.5.6.92, 26.4.5.167, 26.3.17.93

[clickhouse-gh]

Workflow [PR], commit [9bae326]

Summary: ❌

• Performance Comparison: Performance dashboard

job_name	test_name	status	info	comment
Fast test (arm_darwin)		FAIL
	Server died	FAIL	cidb
Stress test (arm_msan)		FAIL
	Cannot start clickhouse-server	FAIL	cidb
	Check failed	FAIL	cidb

---

AI Review

Summary

This PR fixes one bad variant assignment in Iceberg complex schema evolution and adds a regression test for nested Array(Map(Struct(...))) columns. That immediate STRUCT case looks covered, but the same map-value traversal contract is still broken in traverseAllPaths for deeper descendants below the map value, so I do not think the fix is complete yet.

PR Metadata

• Changelog category: Bug Fix matches the user-visible Iceberg schema-evolution regression.
• Changelog entry: required, but Fix typo in complex schema evolution is too internal and vague for the changelog. Suggested replacement: Fixes Iceberg complex schema evolution for nested \Array(Map(Struct(...)))` columns so `ADD COLUMN`, `ALTER COLUMN`, `RENAME COLUMN`, and `DROP COLUMN` no longer throw an exception.`

Findings

• ⚠️ Major: [src/Storages/ObjectStorage/DataLakes/Iceberg/ComplexTypeSchemaProcessorFunctions.cpp:171-190] The map-value traversal contract is still incomplete. transform now carries MAP children correctly, but traverseAllPaths still enqueues the whole (key, value) entry instead of the map value, so paths like x.element.value.element... or x.element.value.value... reach the next ARRAY or MAP step with a Tuple and still throw an exception. Suggested fix: read next_val.safeGet<Tuple>()[1] in that MAP branch as well, then add a regression that nests an ARRAY or MAP under the map value.

Tests

• ⚠️ The new integration test only covers map values that are already STRUCTs, which means traverseAllPaths never has to descend past the map entry. A focused case like Array(Map(Int, Array(Struct(...)))) or Map(Int, Array(Struct(...))) would prove the deeper map-value traversal is wired correctly.

Final Verdict

Status: ⚠️ Request changes

[clickhouse-gh]

Fixing the ARRAY branch here is necessary, but it still leaves deeper descendants under a map value broken. In traverseAllPaths (ComplexTypeSchemaProcessorFunctions.cpp:171-190) the MAP case pushes next_val itself, i.e. the whole (key, value) tuple, instead of next_val.safeGet<Tuple>()[1]; a path such as x.element.value.element... or x.element.value.value... then reaches the next ARRAY/MAP step with a Tuple and still throws before transform runs. Please mirror the MAP handling there as well and add a regression where the map value is an ARRAY or MAP, not just a STRUCT.

[clickhouse-gh]

LLVM Coverage Report

Metric	Baseline	Current	Δ
Lines	86.20%	86.20%	+0.00%
Functions	92.00%	92.00%	+0.00%
Branches	78.30%	78.30%	+0.00%

Changed lines: Changed C/C++ lines covered: 0/2 (0.00%) · Uncovered code

Full report · Diff report