allthingssecurity opened a new pull request, #18804:
URL: https://github.com/apache/iceberg/pull/18804
Since 1.11, workers send the table uuid in `DataWritten`; workers on 1.10 or
earlier do not. During a rolling upgrade both kinds arrive in the same commit,
and `CommitState.tableCommitMap` groups them by the full `TableReference`,
whose `equals` includes the uuid, so one table becomes two groups. The first
group's commit stores the coordinator's whole control-topic position as the
table's `kafka.connect.offsets`, and the second group's `DataWritten` is then
below that position and filtered out as already committed ("nothing to
commit"), or, with several commit threads, fails the offset validation and is
filtered on replay. The workers committed their source offsets in the same
transaction as their `DataWritten`, so those records are never redelivered and
are missing from the table. Separately, when a group decoded from a 1.10 event
is committed, `CommitToTable` re-encodes that `TableReference`, which still
carries the 3-field 1.10 schema, and `TableReference.get` throws `IllegalAr
gumentException: Invalid field position: 3` after the snapshot has landed, so
the coordinator stops on every commit that contains a 1.10 event. This groups
by catalog and table name and checks the uuid of each event when committing (an
event whose uuid does not match the loaded table is still skipped, as before),
and builds a new `TableReference` for `CommitToTable`.
Test plan:
`TestCoordinator#testCommitWithEventsFromWorkersBeforeAndAfterTableUuid`
commits one `DataWritten` encoded by the released iceberg-kafka-connect-events
1.10.0 (`data-written-1.10.0.b64`, no table uuid) and one from the current code
with the uuid, for the same table. Without the change it fails either with
`Expected size: 2 but was: 1` (one worker's file dropped) or with
`IllegalArgumentException: Invalid field position: 3`, depending on which group
is committed first; with it, both files are committed in one snapshot.
`testCommitSkipsEventsForAnotherTableUuid` checks that an event carrying the
uuid of a dropped and re-created table is still skipped while the current
table's event in the same commit is committed. End to end, a test driving the
released 1.12.0 `Coordinator`, `Worker` and `SinkWriter` against a real table,
with the second worker's answer produced by the released 1.10.0 jars in a
separate JVM, lost 3 of 6 records in 18 of 18 runs; re-encoding the same answe
r with the table uuid lost none, and with this change applied to the released
1.12.0 classes all 6 records were committed in 3 of 3 runs with no coordinator
failure. `spotlessCheck`, `checkstyleMain`, `checkstyleTest` and
`:iceberg-kafka-connect:iceberg-kafka-connect:test` (168 tests) pass; the
`kafka-connect-runtime` integration tests (Docker) were not run.
Not addressed here: a 1.10 event cannot be matched to a table instance at
all, so if a table is dropped and re-created under the same name while 1.10
events for it are pending, its files are still committed into the new table.
That needs a separate decision and will be raised as an issue.
---
**AI Disclosure**
- Model: Claude Opus 5.5
- Platform/Tool: Claude Code
- Human Oversight: fully reviewed
- Prompt Summary: Model the Kafka Connect sink's commit protocol in TLA+
with the Specula workflow, reproduce violations against released jars, and
prepare a minimal fix with a regression test. The fix, the tests and this
description are generated.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
