SEZ9 commented on PR #11077: URL: https://github.com/apache/seatunnel/pull/11077#issuecomment-5643204845
Thanks for tracing this through. **F2 (snapshot fan-out / restore-time union)** — I agree the ordering sub-question is fine: `SinkIdentifier` equality is content-based and `getRestoredState()` scans every alias for a destination key, so which alias `groupByIdentity` picks as primary after a restart doesn't matter. But that same analysis sharpens the original concern rather than closing it. If the snapshot path writes the shared writer's state under *every* aliased identifier, a restore that probes all aliases and keeps every non-null entry will hand the connector's `restoreWriter` N copies of the same state. Ordering is only a non-issue if the state is persisted under exactly one identifier per destination key (or de-duplicated on the way out). Could you confirm which of the two the current snapshot path does? If it is fan-out, please either persist under a single canonical identifier or de-dup in `getRestoredState()`, and add a unit test that snapshots a shared writer with two or more aliases and asserts the r estored state list has exactly one entry. Adding a reordered-alias variant to that test would be cheap and would lock in the ordering argument as well. **F3 (schema/config divergence across aliases)** — good, we're aligned on option (a). Concrete ask: at `MultiTableSink` construction, when several identifiers resolve to the same `DestinationKey`, compare the `CatalogTable` schemas (at minimum the physical row type; ideally the relevant sink options too) and fail fast with an error naming the conflicting table identifiers and the destination key. A test with two aliases sharing a destination but differing in schema, asserting the failure, would close this out. The remaining items from the previous review (F1, F4, F5, F6, F7, F8) haven't been addressed in the thread yet — a short status on each (fixed / disagree, with reasoning) would help me re-review efficiently. <!-- streview-comment:993 --> -- 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]
