Describe the bug
After an identity partition field is dropped and a column is re-added, the native writer cannot resolve the partition source column and fails the write:
org.apache.comet.CometNativeException: Unexpected => No column with source column id 2 in schema
Schema { struct: StructType { fields: [NestedField { id: 1, name: "id", required: true,
field_type: Primitive(Long), ... } ...
at org.apache.comet.Native.executePlan(Native Method)
at org.apache.spark.sql.comet.CometIcebergWriteExec.drainAvroPayload(CometIcebergWriteExec.scala:276)
at org.apache.spark.sql.comet.CometIcebergWriteExec.$anonfun$doExecute$9(CometIcebergWriteExec.scala:181)
The partition spec still references source column id 2, which no longer exists in the current schema, and the native manifest encoding treats that as fatal. iceberg-java tolerates it.
Steps to reproduce
Spark 4.1.3, Iceberg 1.11.0, spark.comet.iceberg.write.enabled=true plus the Iceberg Spark SQL test setup from dev/diffs/iceberg/1.11.0.diff:
./gradlew -DsparkVersions=4.1 -DscalaVersion=2.13 -DflinkVersions= -DkafkaVersions= \
:iceberg-spark:iceberg-spark-extensions-4.1_2.13:test \
--tests '*TestAlterTablePartitionFields*' -Pquick=true -x javadoc
Failing case: testReaddColumnAfterIdentityPartitionDrop.
Expected behavior
The write succeeds against a table whose partition spec references a source column that is no longer in the current schema, matching iceberg-java, or the operator declines the write at planning time so it falls back to the JVM writer instead of failing the task.
Additional context
Found by turning the two Iceberg write flags on by default in #5677.
Same test class and same encode_data_files_as_manifest phase as #5691, which panics on a related partition-spec-evolution case. One fix to how the writer resolves the spec against the current schema may close both.
Part of #5649.
Describe the bug
After an identity partition field is dropped and a column is re-added, the native writer cannot resolve the partition source column and fails the write:
The partition spec still references source column id 2, which no longer exists in the current schema, and the native manifest encoding treats that as fatal. iceberg-java tolerates it.
Steps to reproduce
Spark 4.1.3, Iceberg 1.11.0,
spark.comet.iceberg.write.enabled=trueplus the Iceberg Spark SQL test setup fromdev/diffs/iceberg/1.11.0.diff:Failing case:
testReaddColumnAfterIdentityPartitionDrop.Expected behavior
The write succeeds against a table whose partition spec references a source column that is no longer in the current schema, matching iceberg-java, or the operator declines the write at planning time so it falls back to the JVM writer instead of failing the task.
Additional context
Found by turning the two Iceberg write flags on by default in #5677.
Same test class and same
encode_data_files_as_manifestphase as #5691, which panics on a related partition-spec-evolution case. One fix to how the writer resolves the spec against the current schema may close both.Part of #5649.