DanielLeens commented on issue #11355: URL: https://github.com/apache/seatunnel/issues/11355#issuecomment-4888296112
This is a reasonable CDC design direction, and the operator problem is real: today users often can tell that a DDL-related problem happened, but not which decision path the pipeline actually took. The part I would make explicit before implementation is the boundary of this “decision log”. In particular: 1. which lifecycle events are in scope for V1 2. whether this is a lightweight observability view or a stronger audit/history contract 3. how much data is retained, and where that retention responsibility lives 4. how the model stays useful across single-table, multi-table, and routed CDC paths without forcing every connector into a completely different shape A good first delivery would be much easier to review if it starts with a narrow event model: source DDL arrival, target resolution, applied policy, sink capability decision, and final outcome. That already solves a large part of the current diagnosis gap without making the initial design too heavy. So I agree this is worth tracking, but it should move forward as a scoped design/enhancement issue rather than a direct implementation request. -- 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]
