SEZ9 commented on PR #11512: URL: https://github.com/apache/seatunnel/pull/11512#issuecomment-6258881262
Thanks for the update. Looking at the latest automated pass on `d2f8193c97`, it reports no new source-level blocker on the reporting path, generation/owner checks, and the explicit codec's collection-size validation, which lines up with the direction we discussed. What it does not do is close out my earlier F1-F8 list explicitly, so I want to make sure none of those fall through the cracks before merge. Could you confirm the status of each item against `d2f8193c97` (the pointers from the earlier pass were against `9cf8e059b8`, so please note anything that moved): - **F1 (`CdcEnumeratorProgressReport.activeSplits` bound):** is the list now capped to match the "bounded active-split details" contract, or is the bound enforced only at the codec? If the latter, the Javadoc should say so. - **F2 (secrets in position payloads):** does `docs/en/developer/cdc-progress.md` now state that connector-native position payloads must not contain credentials or connection secrets, given they are shipped to and stored on the coordinator? - **F3 (enum encoding):** are `CdcProgressAccuracy` and the other new API enums written by name rather than ordinal in the explicit engine codec? A one-line round-trip test asserting the encoded name would settle this. - **F4 (pull/derive vs. registration-based collection):** has the runtime-collection section been reworded to describe the coordinator-owned, registration-based enumerator report path the PR actually implements? - **F5 (implementing connectors):** does the developer doc now list which connectors currently implement the progress provider? - **F6 (`CdcProgressLifecycle.SNAPSHOT` Javadoc):** has the enumerator-owned discovery/assignment wording been removed so it matches the ownership rule in the doc? - **F7 (count invariants):** do the count fields now reject negative and mutually inconsistent values, or is that deliberately left to the codec/caller? - **F8 (element immutability):** is the "immutable per-split details" claim either backed by `CdcSnapshotSplitProgress` being immutable itself, or softened to describe the shallow copy accurately? A short per-item "fixed in head / deferred to follow-up / disagree because ..." is all I need. Items you want to defer are fine as long as they are called out in the PR description so we track them. Once I have that mapping I'll do my final pass on `d2f8193c97`. <!-- streview-comment:1866 --> -- 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]
