DanielLeens commented on issue #11364: URL: https://github.com/apache/seatunnel/issues/11364#issuecomment-4975705310
Yes — this revision answers the main runtime-boundary questions well enough to move from STIP refinement into a narrower implementation pass. What is now clear enough for review: 1. the reporting path from worker/master sampling to coordinator-side latest snapshot 2. the separation between lifecycle, recovery, and health semantics 3. the aggregation boundary between reader reports, enumerator reports, and source-level summary 4. the restore origin model, instead of asking connectors to infer restore from normal split assignment 5. the canonical v1 response shape and the bounded payload rule From my side, the important next step is to keep PR #11395 aligned with the implementation slices you listed, instead of trying to land the whole public contract at once. I would suggest reworking #11395 so the first pass stays focused on: - the experimental internal report model - periodic worker/master transport and latest-snapshot aggregation - one complete MySQL validation path Then keep these as explicit follow-up slices unless they are needed by that first proof: - public `seatunnel-api` stabilization - PostgreSQL validation - broader REST exposure refinements beyond the bounded v1 shape One thing to keep very visible in the PR description is which fields are already contract-worthy versus which parts are still experimental and validated only through the MySQL-first path. That will make it much easier for reviewers to judge compatibility risk. So overall: the STIP boundary now looks solid enough to rework #11395 and continue with a narrow first implementation. -- 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]
