The GitHub Actions job "Build" on rocketmq-clients.git/master has succeeded. Run started by GitHub user lizhimins (triggered by lizhimins).
Head commit for run: 98822d9fae4e1f298c4d723b6f8f54480f19297e / Lei Zhiyuan <[email protected]> fix(rust): align log messages and levels with the Java client (#1472) The Rust client logged at INFO on every settings push and every received batch, used its own wording, and refreshed settings on a schedule unrelated to Java's, so its logs were both noisier and harder to correlate with the Java client's (#1471). Align the messages, levels and fields (clientId, endpoints, mq, consumerGroup, ...) with the Java client across telemetry, client lifecycle, heartbeat, routes, sessions, producer, simple consumer, push consumer, process queue and lite consumers, and adopt Java's schedules for the settings sync (1s delay / 5 min period) and the statistics log (1s / 60s). Three periodic logs Java keeps at INFO stay at DEBUG here, because at the default level they would make the Rust client log more than before: a successful heartbeat, a route fetch whose route did not change, and the start of a refresh round. The 30s timer used to both push settings and rebuild broken streams. Java needs no rebuild because ClientSessionImpl#renewRequestObserver retries every second without a limit, while the reconnect loop here gives up after 8 attempts, so the timer is split: the settings sync moves to Java's schedule, and a new SessionManager::recover_broken_streams runs every 30s and only touches sessions whose stream is gone. The route refresh keeps the 10s of #1404, which bounds how long a client keeps sending to a stale endpoint after a failover. Also fix three defects found while aligning: - Client::shutdown_ref returned early when the termination notice failed, so the scheduler and the telemetry sessions were never released. It now logs the failure and still releases everything, like ClientImpl#shutDown. - Producer, SimpleConsumer and PushConsumer did not shut the client down when a start failed after Client::start, leaving the scheduler and the sessions running after start() had returned an error. A ClientIsNotRunning from the cleanup is tolerated, any other cleanup failure is logged. - LiteSimpleConsumer's telemetry loop caught a closed channel in a debug catch-all arm, so recv() returned None immediately and spun the task. Left on purpose: the ack / nack / DLQ logs carry no requestId because the Rust session does not surface it; Producer::send has no local retry, so a failed send is logged as maxAttempts=1; the queue statistics report no cachedMessageCount / cachedMessageBytes because there is no message cache; and assignment scanning before the first settings arrive is a DEBUG skip where Java waits for them during startup. The assignment scan (30s vs Java's 5s) and the idle session cleanup (30s vs Java's 1 min) keep their periods for now and only have their logs aligned. Add util::test_log::capture(), a test-only tracing subscriber that records events, so tests can assert on the level and the content of what the client logs. Report URL: https://github.com/apache/rocketmq-clients/actions/runs/41764342136 With regards, GitHub Actions via GitBox
