DanielLeens commented on issue #11749: URL: https://github.com/apache/seatunnel/issues/11749#issuecomment-5247866937
Thanks for writing this up with the exact close path. I checked the current Neo4j connector code, and this is a real resource-release bug. In the sink, `close()` still executes `flushWriteBuffer() -> session.close() -> driver.close()` as plain sequential calls, so any exception from the final flush prevents both the session and the driver from being closed. The source reader has the same shape: if `session.close()` throws, `driver.close()` is skipped. That means this is not only a one-off teardown annoyance: it can leak the driver's connection pool and background resources precisely on the failure path where cleanup matters most. A good fix here would be to make both close paths best-effort and exception-safe: - always attempt to close both session and driver; - preserve the primary failure from flush / close; - attach later cleanup failures as suppressed exceptions instead of losing the original cause. Please also cover both sink and source sides together, with a regression test that proves the second resource is still closed when the first step fails. You marked that you are willing to submit the PR. I also tried to assign the issue accordingly, but GitHub did not accept the assignee update from my side, so please continue on the PR path and we can keep tracking progress here. -- 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]
