DanielCarter-stack commented on issue #10581: URL: https://github.com/apache/seatunnel/issues/10581#issuecomment-4022685225
<!-- code-pr-reviewer --> Thank you for the proposal—this is a valuable feature for large-scale multi-table sync scenarios. **Current state:** This capability does not exist yet. Key evidence: - No `multi_table.failure_policy` config in `EnvCommonOptions.java` (L28-100) - `MultiTableSinkWriter.subSinkErrorCheck()` (L134-143) throws `RuntimeException` immediately on any single-table failure - SaveMode failures in `MultipleTableJobConfigParser.handleSaveMode()` (L728-747) terminate the entire job via `SeaTunnelRuntimeException` - No `FailedTableRegistry` or structured failure reporting component exists Your proposed design is sound: keeping `FAIL_FAST` as default, distinguishing table-scoped vs system errors, and avoiding a new `JobStatus.PARTIAL`. **A few questions to clarify:** 1. For SaveMode failures under `CONTINUE_OTHER_TABLES`, should the system skip the affected table or abort the job? 2. How should Source-side errors (e.g., CDC binlog parse failure) be classified as table-scoped—should connectors explicitly mark error isolatability? 3. Where should the failure report be output—logs only, or exposed via REST API? This would be a high-value but complex change across `MultipleTableJobConfigParser`, `MultiTableSinkWriter`, and `CheckpointCoordinator`. Phased implementation (SaveMode/Sink isolation first, Source isolation later) seems appropriate. -- 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]
