Failure-injection tests for native Iceberg writes

[andygrove]

What is the problem the feature request solves?

The native Iceberg write path has documented failure semantics (mid-task failure retries with attempt-unique file names, partial results are never committed, commit failures reuse SparkWrite.abort), and two known gaps (#5618 task-attempt cleanup, #5277 orphans on commit failure). What it does not have is tests that inject failures and assert those semantics hold. CometIcebergWriteActionSuite has one commit-time conflict test and one aborted-job test; neither fails inside the native writer, and neither checks what files are left behind.

Describe the potential solution

Add a failure-injection section to the Iceberg write tests covering, for the native path:

• A task that fails inside iceberg-rust after at least one data file has been finalized (for example an object store that starts rejecting writes after N puts, using the in-memory or a wrapped file:// store): the retry succeeds, the table commits exactly once, and no file from the failed attempt is referenced by any manifest.
• A task that fails after the native writer returns but before TaskCommit (manifest decode or metrics rebuild throws): same assertions, plus the paths from the decoded manifest are deleted once Native Iceberg write: clean up task-attempt data files on task failure #5618 lands.
• A commit failure after all tasks succeed: the table is unchanged, and once Remove orphaned files in comet iceberg split writers #5277 lands, no data files from the attempt remain.
• Speculative execution: two attempts of the same task both finish; exactly one set of files is committed.
• Executor loss mid-write on a multi-task write: the stage retries and the final row count is exact.

Each test should assert both the visible outcome (rows, snapshot count) and the storage state (files under the data location versus files referenced by manifests), since the orphan gaps are invisible to readers.

Additional context

Part of the native Iceberg writes epic, #5649. Related: #5618, #5277, #5361 (introduced the failure-handling section in iceberg-writes.md).

[sam-1112]

take

[sam-1112]

I’d like to split #5646 into four PRs, each focused on a distinct failure boundary:

1. Native writer failure mid-write, followed by a successful retry. (test: cover native Iceberg mid-write retry cleanup #6111 )
2. Failure after the native writer returns but before the JVM creates TaskCommit(test: cover native Iceberg write handoff cleanup #6117 ).
3. Driver commit failure after all tasks succeed.(test: cover Iceberg driver commit cleanup #6119 )
4. Spark scheduler failures: speculative execution and executor loss during a multi-task write.