SEZ9 commented on PR #11077: URL: https://github.com/apache/seatunnel/pull/11077#issuecomment-5754487058
Thanks for the quick fix on the compile break. I re-checked the `65b28547c0..1bfcea62b6` diff and it is exactly what you describe: only `MultiTableSink.java` changes, with the two `final SinkWriter<SeaTunnelRow, ?, ?> sharedWriter = writer;` locals and the two INFO-log lambdas now capturing `sharedWriter` on both the create and restore paths. That resolves the "local variables referenced from a lambda must be final" error, so the blocker from the last round is done. On F1 and F2: javadoc and a log line help visibility, but by themselves they do not close either finding, since both are about behavior rather than documentation. - **F1 (destination-key collision / cross-destination routing)**: please point me to where a collision between two aliases that are *not* actually the same physical destination is detected or rejected, rather than only logged. If the intent is that this stays the connector's responsibility via `getPhysicalDestinationIdentifier()`, say so explicitly in the reply and in the Javadoc so I can evaluate it on that basis. - **F2 (snapshot fan-out + restore-time union duplicating shared-writer state N times)**: please describe, or add a unit test showing, that after a snapshot with N aliases on one shared writer and a subsequent restore, the writer receives its state exactly once. A quick note on how the legacy per-alias records are merged without re-adding the same state N times would be enough for me to re-verify. Remaining asks before I can approve: 1. Concrete answers (or tests) for F1 and F2 as above. 2. A status line for F3 through F8 — either "addressed in 1bfcea62b" with a pointer, or "not yet / deferred with reason". I could not tell from the comment which of those are covered. Once those are in the thread I will do the re-review promptly. <!-- streview-comment:1197 --> -- 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]
