leizhiyuan opened a new issue, #1426: URL: https://github.com/apache/rocketmq-clients/issues/1426
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq-clients/issues) and [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Programming Language of the Client Rust ### Runtime Platform Environment macOS 27 (arm64) ### RocketMQ Version of the Client/Server Client: Rust `rocketmq` 5.0.0, master `a3d1de8b` Server: a managed RocketMQ 5.x service (Tencent Cloud TDMQ for RocketMQ 5), gRPC proxy endpoint ### Run or Compiler Version rustc 1.98.0 ### Describe the Bug `SimpleConsumer::receive_with` and `SimpleConsumer::change_invisible_duration` do not validate their arguments. A negative batch size **panics** the calling task, a zero batch size goes to the server, and an invisible duration that protobuf can not represent also panics. **Scenario.** The batch size and invisible duration are usually computed or read from configuration (e.g. "remaining capacity" of a worker pool, or a duration parsed from a config file). A bug or a misconfiguration that yields `0`, a negative value or a huge duration should come back as an error. Today it either crashes the task or turns into a silent 20 s long poll. Observed on a real server with a normal topic and group: | call | Rust today | Java 5.2.2 | |---|---|---| | `receive_with(topic, expr, 0, 10s)` | sent to the server, returns `Ok([])` after the full long polling time (20 s) | `IllegalArgumentException: maxMessageNum must be greater than 0`, no RPC | | `receive_with(topic, expr, -1, 10s)` | **panic** `capacity overflow` | same as above | | `receive_with(topic, expr, 1, Duration::MAX)` | **panic** in `prost_types::Duration::try_from(..).unwrap()` | (n/a, Java `Duration` is converted with `Durations.fromNanos`) | | `change_invisible_duration(&view, Duration::MAX)` | **panic**, same unwrap | (n/a) | Where: - `-1` panics in `Client::receive_message_inner` at `Vec::with_capacity(batch_size as usize)` (`client.rs`): `-1i32 as usize` is `usize::MAX`. `Session::receive_message` has the same pattern. - `simple_consumer.rs` converts the invisible duration with `prost_types::Duration::try_from(invisible_duration).unwrap()` in both `receive_with` and `change_invisible_duration`. The conversion fails when the seconds do not fit into `i64`. **Java behavior.** `SimpleConsumerImpl#receive0` checks before any RPC: ```java if (maxMessageNum <= 0) { final IllegalArgumentException e = new IllegalArgumentException("maxMessageNum must be greater than 0"); return Futures.immediateFailedFuture(e); } ``` ### Steps to Reproduce ```rust let consumer = /* started SimpleConsumer */; let expr = FilterExpression::new(FilterType::Tag, "*"); consumer.receive_with("topic", &expr, -1, Duration::from_secs(10)).await; // panics: capacity overflow consumer.receive_with("topic", &expr, 0, Duration::from_secs(10)).await; // Ok([]) after 20 s consumer.receive_with("topic", &expr, 1, Duration::MAX).await; // panics ``` ### What Did You Expect to See? An error returned immediately, without an RPC, as the Java client does: - `batch_size <= 0`: "batch size must be greater than 0" - an invisible duration that can not be represented: an error instead of a panic ### What Did You See Instead? A panic for a negative batch size or a huge duration; a wasted long poll for a zero batch size. ### Additional Context Found while comparing the Rust and Java SimpleConsumer end to end on the same server. --- Tracked in #1412. -- 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]
