Iceberg ADD COLUMN of nested types fails commit-unknown recovery with Column already exists

[DimensionWieldr]

Describe the bug

Iceberg ALTER retry after a “commit state unknown” catalog response does not detect that an ADD COLUMN of a nested type (Array / Map / Tuple) already landed. The retry then fails with Column already exists.

Primitive ADD COLUMN … Nullable(String) recovers correctly. Nested types do not.

Found while testing PR #2157. Split out of this comment.

To Reproduce

On 26.6.2 (PR #2157), REST catalog, failpoint iceberg_alter_catalog_commit_reported_as_failed (ONCE):

SET allow_insert_into_iceberg = 1, enable_nullable_tuple_type = 1;
ALTER TABLE datalake.`namespace.table` ADD COLUMN tuple_col Nullable(Tuple(Int32, String));

The failpoint applies the catalog commit then returns false (Iceberg “commit state unknown”).

Expected behavior

Retry should see the nested column already in the schema and succeed, same as primitive ADD COLUMN.

Actual behaviour

Code: 36. DB::Exception: Column tuple_col already exists. (BAD_ARGUMENTS)

The catalog already committed the column. Recovery missed it.

Key information

• Project Antalya 26.6.2 (PR Antalya 26:6 Fix alter operations for iceberg #2157)
• Iceberg catalog: REST

Additional context

isAddColumnApplied rebuilds the expected Iceberg type via getIcebergType(type, last_column_id) from the current last-column-id (already advanced by the successful commit).

For primitives that is a string ("string", "long", …) and the compare succeeds.

For Array / Map / Tuple, getIcebergType allocates new nested field ids. icebergTypesEqual stringifies JSON, so element-id / key-id / value-id / struct field ids do not match → false → retry → Column already exists.