Need to investigate: what state may be changed during export process.
For example:
EXPORT PARTITION reads destination metadata multiple times during request validation and background execution. A concurrent schema change may therefore cause the sink, converting ActionsDAG, and commit logic to use different metadata snapshots. For Iceberg, the final schema-ID check prevents publishing inconsistent data, but the task may fail late after writing files. For non-Iceberg destinations (MergeTree - MergeTree ?, MergeTree- object storage) there is no equivalent late commit-time check at all, so the same drift can go through completely unnoticed - a lossy cast or partition-key mismatch introduced by a concurrent ALTER on the destination is never re-validated once the export part task has started.
Possibly capture and consistently use a single destination metadata snapshot per worker task, and validate the pinned Iceberg schema before writing.
Need to investigate: what state may be changed during export process.
For example:
EXPORT PARTITIONreads destination metadata multiple times during request validation and background execution. A concurrent schema change may therefore cause the sink, converting ActionsDAG, and commit logic to use different metadata snapshots. For Iceberg, the final schema-ID check prevents publishing inconsistent data, but the task may fail late after writing files. For non-Iceberg destinations (MergeTree - MergeTree ?, MergeTree- object storage) there is no equivalent late commit-time check at all, so the same drift can go through completely unnoticed - a lossy cast or partition-key mismatch introduced by a concurrent ALTER on the destination is never re-validated once the export part task has started.Possibly capture and consistently use a single destination metadata snapshot per worker task, and validate the pinned Iceberg schema before writing.