Skip to content

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

Description

@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

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions