[bvolpato]

BigQuery Storage Write API writers remove rejected payloads and timestamps before retrying a batch, but leave failsafe rows in their original positions. When withFormatRecordOnFailureFunction is set, a later serialization error can select the wrong original row for the failure output, duplicating one record and omitting another.

This change filters failsafe rows alongside payloads and timestamps in both writers. Nullable entries used for protobuf-to-TableRow fallback are preserved. The API defines row-error indexes relative to the current request.

Local regression validation passed with controlled append responses. A recorded live BigQuery run also reproduced the misattribution after a partial row-error response. That response size was observed in the run and is not an API guarantee.

Run the GCP module tests with:

./gradlew :sdks:java:io:google-cloud-platform:test

---

• If this contribution is large, please file an Apache Individual Contributor License Agreement.
• Replace these instructions with a description of your change and why you have made it.
• Mention the appropriate issue in your description (for example: addresses #123 or fixes #456).
• Update CHANGES.md with noteworthy changes.

See CONTRIBUTING.md for contribution guidelines.

[github-actions]

📋 Review Summary

This PR fixes a bug in the BigQuery Storage Write API writers (StorageApiWriteUnshardedRecords and StorageApiWritesShardedRecords) where failsafeTableRows was not filtered alongside protoRows and timestamps when removing failed rows before retrying a batch after an AppendSerializationError. This caused subsequent serialization errors on retried batches to reference the wrong index in failsafeTableRows, emitting misattributed original records to the failure output.

🔍 General Feedback

• The fix is clean, minimal, and consistently applied across both sharded and unsharded Storage Write API implementations.
• The added parameterized test (StorageApiWriteRetryTest) thoroughly covers both STORAGE_WRITE_API (batch and streaming) and STORAGE_API_AT_LEAST_ONCE modes, verifying that multi-row batch retries preserve the exact original rows.

---

💡 Tip: Comment /gemini review on this pull request to trigger a new Gemini code review.

[github-actions]

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

[github-actions]

Assigning reviewers:

R: @kennknowles for label java.
Backup reviewer: ahmedabu98 (if the main reviewer is unresponsive, you can escalate to them by tagging their username)

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).