DanielLeens commented on issue #11769: URL: https://github.com/apache/seatunnel/issues/11769#issuecomment-5327992422
Thanks, that narrows the reproduction further. I re-checked the current `dev` JDBC sink path with your clarification in mind. The important point is that this is not only a generic reconnect case anymore; it is the multi-table JDBC sink path with `generate_sink_sql = true`. On current `dev`, we do have reconnect coverage in `JdbcOutputFormatReconnectTest`, but those tests only prove that `flush()` can detect `08xxx` / `statement closed` SQLExceptions, call `updateExecutor(true)`, and re-prepare statements. They do not cover a multi-table writer rebuilding statements and replaying buffered rows correctly after reconnect under generated-SQL mode. So your new detail is useful because it gives us a much tighter regression target for the second fix. I would keep #11771 scoped to the pool-validation gap, and track the remaining fix here as: 1. reproduce the failure with multi-table + `generate_sink_sql = true`; 2. verify statement rebuild + buffered-row replay after reconnect on the active table path; 3. keep this issue open until that path has a focused regression test and fix. If someone extends the implementation, please make the regression target this exact configuration rather than only a generic single-table reconnect case. -- 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]
