DanielLeens commented on PR #11494: URL: https://github.com/apache/seatunnel/pull/11494#issuecomment-5190591222
Thanks @SEZ9 for staying on this one too — I want to push back gently on the Issue 1 conclusion this time, with the evidence for why. I checked the current `dev` baseline for the two methods this concern is about: - `DefaultReader.readData(Path path)` is already `private` on `dev` (`DefaultReader.java:89`). A private method has no external callers by definition, so a signature change here — streaming via `forEachData`/`RecordConsumer` instead of returning a `List` — cannot be a public API break; it's an internal implementation detail of one class. - `IFileReader.readAllData(Path parentPath)` stays on the interface as a default method specifically so that any third-party `IFileReader` implementation that only overrode the old method keeps working — this is exactly the "Backward-compat path" your own 2026-07-22 review traced (`IFileReader.forEachData` default impl falling back to `readAllData`). That's the one place a real downstream implementer could be affected, and this PR deliberately keeps it in place rather than removing it. `WALReader` itself is internal `seatunnel-engine-storage` plugin code, not a `SeaTunnelSource`/`SeaTunnelSink` SPI surface, so there's no connector-facing contract riding on its method shapes either. Given that, I'm keeping my 2026-08-04 approval as Daniel's current conclusion: no open source-side blocker from my side on this head (`bccb2761`), recovery semantics unchanged, WAL format unchanged, checks green. If you're aware of a concrete external caller of `DefaultReader.readData` or a specific `IFileReader` implementation outside this module that would break, I'd genuinely like to see it — happy to reopen the blocker with that evidence. Note I only have read-level review permission here, so a write-capable maintainer still needs to handle the actual merge/approval-state step regardless of how this discussion resolves. -- 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]
