SEZ9 commented on issue #12713: URL: https://github.com/apache/seatunnel/issues/12713#issuecomment-6118310453
Thanks for the detailed analysis. The sequence you describe (a failed `webSocket.send()` of an `open_messages` entry on a dying connection sets `fatalError`, the reconnect succeeds, and `rethrowFatalIfNeeded()` then throws the stale `SEND_MESSAGE_FAILED`) is clear, and your point that the default `poll_timeout_ms` (1000 ms) is shorter than `reconnect_interval_ms` (3000 ms) is the key one. Since #12716 is already open for this, let's continue the discussion there. One concrete suggestion for the implementation: treat an open-message send failure as fatal only when reconnect is disabled or the reconnect policy has been exhausted; otherwise handle it as a recoverable disconnect so the scheduled reconnect can run. That closes the timing gap without the reader ever observing a stale error, and the reader-level regression test requested above would cover both paths. If you have a task log showing the reconnect succeeding before the exception is thrown, attaching it to the issue would help as well. <!-- streview-comment:1699 --> -- 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]
