The GitHub Actions job "Java Coverage" on rocketmq-clients.git/master has succeeded. Run started by GitHub user RongtongJin (triggered by RongtongJin).
Head commit for run: 3c0849e992771986b5690f6a169d4afdcef0b2f7 / zhaohai <[email protected]> fix(go): robust consumer settlement, reception backoff, and shutdown under failures (#1473) * fix(go): give up dead settlement retries and stop swallowing settlement errors - move the INVALID_RECEIPT_HANDLE abandon branch of defaultProcessQueue.changeInvisibleDuration before the generic err handling: changeInvisibleDuration0 converts a non-OK status into an error, so the branch was unreachable and an expired receipt handle was renewed once a second forever - cap the ack / change invisible duration / forward-to-DLQ retry chains at 3 attempts and stop scheduling retries once the process queue was dropped or the consumer is no longer running; the DLQ chain also forgives INVALID_RECEIPT_HANDLE (it never gave up on any code) - restore the Java semantics of the receiving back-off delays: the default is RECEIVING_FAILURE_BACKOFF_DELAY (1s) and only flow control retries after the short RECEIVING_FLOW_CONTROL_BACKOFF_DELAY (20ms) - SimpleConsumer.ChangeInvisibleDuration: only adopt the receipt handle from a successful response; a failed request used to wipe the handle to the empty string and make every following call fail permanently - SimpleConsumer.Ack: return the server status instead of nil on a non-OK response - fix mis-copied "message acknowledgement" log text in the renewal and DLQ failure paths and replace %w verbs that zap does not expand * fix(go): stop receive hammering, throttle reception failure logs, and bound GracefulStop under proxy restart - Remove the 20ms TOO_MANY_REQUESTS reception backoff: real proxy flow control means the executor queue is saturated, and retrying at ~50 polls per second only hammers it harder; every reception failure now waits the full 1s backoff. - Throttle reception-failure logging: the first failure logs ERROR, then one WARN per 30 consecutive failures carrying the cumulative count, the rest only DEBUG; the counter resets on success and on MESSAGE_NOT_FOUND, so a sustained outage no longer emits one ERROR per second per queue. - GracefulStop now cancels in-flight long polling receive requests via a consumer-scoped receive context, so shutdown no longer waits out requestTimeout + longPollingTimeout for a poll hanging against a restarting proxy. - notifyClientTermination runs concurrently across route targets, so the shutdown no longer stretches by a full request timeout per target. - Replace remaining Java-style {} placeholders with fmt verbs in process_queue.go and push_consumer.go logs. - Add tests: ack settlement retries are capped and complete; GracefulStop cancels an in-flight receive request instead of waiting it out. * fix(go): keep assignments when the assignment scan fails and fix clientId verb A failed queryAssignments does not mean the server has no assignments: syncing the nil result dropped every working process queue and stalled consumption for the whole outage. The scan now keeps the current assignments until the next successful one, so the reception chain keeps running (and its failure logging stays throttled) while the proxy or broker is down. Also fix clientId=%d printing %!d(string=...) in the empty-assignments warning, found during the local cluster test. Report URL: https://github.com/apache/rocketmq-clients/actions/runs/41422398947 With regards, GitHub Actions via GitBox
