TomPlanche opened a new pull request, #4507: URL: https://github.com/apache/iggy/pull/4507
## Which issue does this PR address? Relates to #4287 (problems 5 and 7) ## Rationale `shutdown()` must be final, also for a reconnect that runs at the same time. This fix needs `shutdown()` to set `Shutdown` before it closes the connection, and that order is also the fix for problem 7. ## What changed? A reconnect that ran during `shutdown()` did not stop. Its next dial installed a connection and published `Connected` on a client that was shut down. On TCP, a failed close in `shutdown()` returned before it set `Shutdown`, so the client stayed usable. Now a reconnect stops with `ClientShutdown` before each dial and right after it installs a connection, on TCP, QUIC and WebSocket. `shutdown()` sets `Shutdown` first. Thus, when a dial completes during the shutdown, either `shutdown()` or the reconnect closes the new connection. On TCP, `shutdown()` logs a failed close and continues. ## Local Execution - Passed: `cargo fmt`, `cargo sort --no-format` and `cargo clippy --all-features --all-targets -- -D warnings`. - Passed: `cargo test -p iggy --lib` (297 tests). - Passed: the `sdk::` and `cluster::` integration suites (174 passed, 3 ignored as on master). - Passed: the three new tests, one for each transport, fail on master. After the shutdown, TCP returns `Ok(())`, and QUIC and WebSocket dial the server again. - Passed: `prek run --files` on the changed files. - Not tested: problem 7. A failed close needs a TLS peer reset, and no unit test provokes it. ## AI Usage 1. No ^^ -- 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]
