The GitHub Actions job "Build" on rocketmq-clients.git/fix/rust-telemetry-session-defects has failed. Run started by GitHub user zhaohai666 (triggered by zhaohai666).
Head commit for run: 5fad37c3ad654e7ce109adf575356253b5519b8c / zhaohaihzb <[email protected]> fix(rust): bound the reconnect loop, rebuild evicted sessions, fix MSRV pins and keep-alive interval Follow-up on the proactive reconnect, addressing real-cluster findings: * A session that was evicted or reaped meanwhile made `reconnect_session` return `Ok(())`, which the reconnect retry loop treated as "stream re-established" and exited without any stream. A missing session is now rebuilt from the access endpoints instead (`Ok(bool)` tells the loop whether the stream was really restored). The lock is released before that rebuild: `get_or_create_session` takes the same map lock, and holding it across the rebuild dead-locked the tokio mutex. * The retry loop is bounded: the delay doubles from 1s up to a 30s cap and the loop gives up after 8 attempts (~2 minutes), leaving a permanently offline endpoint to the periodic settings sync, the heartbeat and the next business traffic instead of hammering it once a second forever. Every attempt is logged with its index and next delay. * The periodic topic-route sync drops from 30s to 10s: when a broker endpoint drifts, the stale-route window (measured 13-29s) is decided by that timer, not by the telemetry reconnect. * The HTTP/2 keep-alive interval drops from 300s to 60s: the proxy permits client pings every 30s by default (`ProxyConfig# grpcServerPermitKeepAliveTimeMillis = 30000`, overriding the bare grpc-java 5-minute default), so a dead peer is now detected within ~90s instead of ~330s. The Java client does not configure keep-alive at all, so the previous "aligned with Java" comment was wrong. * MSRV 1.74 broke on fresh dependency resolution (as the CI build does every run): pin `hyper-util <0.1.16` (edition 2024), `powerfmt <0.2.1` (rustc 1.79) and `tokio <1.47` (rustc 1.85). Verified on a live cluster: after `kill -9` of the proxy the reconnect loop logged attempts 1/8 (1s), 2/8 (2s), 3/8 (4s) ... and re-established the stream on attempt 5; the first successful receive happened 79ms after the new instance became ready. Report URL: https://github.com/apache/rocketmq-clients/actions/runs/39403736851 With regards, GitHub Actions via GitBox
