You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "leizhiyuan (via GitHub)" <gi...@apache.org> on 2026/10/20 12:37:31 UTC
[I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
leizhiyuan opened a new issue, #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412
### Before Creating the Enhancement Request
- [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature.
### Programming Language of the Client
Rust
### Summary
This is a tracking issue for the Rust client. It brings together:
- the defects found by an end-to-end test of `LitePushConsumer` / `PushConsumer` against a managed RocketMQ 5 server, with the Java client 5.2.2 run against the same server, group and topic as a control;
- the Rust issues and PRs that are already open.
The goal is that reviewers can see what each PR fixes, where they overlap, and in which order they can be merged with the least rebase work. I will keep the lists below up to date.
### Motivation
- Six Rust PRs are open, and most of them touch the same few files (`push_consumer.rs`, `lite_subscription_manager.rs`, `client.rs`, `lib.rs`). Several pairs conflict with each other, and two of them implement overlapping logic (see below).
- On servers that return the assigned topic name in a decorated form, `LitePushConsumer` on `master` cannot receive any message (#1406). Unsubscribing never works (fixed in #1381). The lite subscription quota is not enforced (#1408). These should be fixed before a release that advertises LiteTopic support (#1400).
- #1361 (Support LiteSimpleConsumer) was closed by the stale bot while its PR #1381 is still open. It may be worth reopening it.
### Describe the Solution You'd Like
#### Open Rust issues and PRs
| Issue | PR | Topic | Files |
|---|---|---|---|
| #1406 | #1407 | PushConsumer takes the filter expression from the subscription, not the assigned queue's topic name; backoff on receive failures | `push_consumer.rs` |
| #1408 | #1409 | LitePushConsumer applies server `Settings` / `NotifyUnsubscribeLiteCommand`; `start()` waits for the first `Settings`; quota `0` no longer means unlimited | `push_consumer.rs`, `lite_push_consumer.rs`, `lite_subscription_manager.rs`, `lib.rs` |
| #1410 | #1411 | A panic in the message listener is treated as `FAILURE` instead of killing the worker | `push_consumer.rs`, `client.rs` (test lock only) |
| #1403 | #1404 | Telemetry session recovery after proxy rolling update, bounded session map, keep-alive, receive deadline, server-pushed settings | `session.rs`, `client.rs`, `conf.rs`, `push_consumer.rs`, `simple_consumer.rs`, `Cargo.toml` |
| #1361 (closed by stale bot) | #1381 | LiteSimpleConsumer; also fixes `lite_topic` missing in ack / change-invisible-duration and `unsubscribe_lite` always failing; cancellable periodic sync | `lite_*`, `client.rs`, `simple_consumer.rs`, `util.rs`, `lib.rs`, `Cargo.toml`, ... |
| #1400 | — | Request a new release with LiteTopic support | — |
| #488 | — | End-to-end tests for the Rust client | — |
#### Defects found by the end-to-end test
| # | Defect | Java behavior | Status |
|---|---|---|---|
| 1 | PushConsumer / LitePushConsumer never receives messages when the assigned queue's topic name differs from the subscription key (e.g. `<instance>%<topic>`); the receive loop then spins every 1 ms with no backoff (8.9M error lines in 8 min) | filter expression comes from the subscription; 1 s / 20 ms backoff | #1406 / #1407 |
| 2 | `unsubscribe_lite` always fails with `ClientIsNotRunning` (`check_started` on the cloned client) | works | fixed in #1381 |
| 3 | LitePushConsumer never applies server lite settings or `NotifyUnsubscribeLiteCommand`; quota not enforced (2010 subscriptions accepted with quota 2000) | 2001st rejected with `42902` | #1408 / #1409 |
| 4a | `shutdown()` takes 20–345 s: in-flight long polls are not cancelled, and actors are shut down one by one | ~6 s | not filed yet |
| 4b | the periodic lite sync task is not cancelled on shutdown and re-creates a session afterwards | cancelled | fixed in #1381 (`stop_scheduler`) |
| 5 | FIFO local retry: `MessageView::delivery_attempt()` seen by the listener stays at 1 | `incrementAndGetDeliveryAttempt()` | not filed yet (next) |
| 6 | `batch_send` of lite messages returns `Ok` with one receipt holding comma-joined ids, and the messages are never consumed | no public batch API | investigating (server or client not yet known) |
| 7 | a panic in the message listener kills the consumer worker for good | `catch (Throwable)` → `FAILURE` | #1410 / #1411 |
| 8 | receive gRPC deadline equals the long-polling timeout, so every idle long poll ends with an ERROR | `awaitDuration + requestTimeout` | fixed in #1404 (also #1403) |
| 9 | FIFO vs. standard worker is chosen from the local option, not from the server settings | `getSettings().isFifo()` | partly in #1404 (PushConsumer); LitePushConsumer to be verified once #1404 and #1409 are in |
| 10 | lite examples use `http://localhost:8080`, which fails with a DNS error | — | not filed yet |
| 11 | `MessageBuilder` accepts a blank lite topic; the error only comes from the server (`40014` / `40020`) | `isNotBlank` check | not filed yet |
| 12 | LitePushConsumer pre-fetches the route before the client is started, logging a WARN on every start | — | not filed yet |
Other observations, not filed: an intermittent `h2 ... frame with invalid size` when the telemetry stream starts (about 2 in 20 starts, cause unknown). The `tail_n` and `timestamp` offset options have no effect either, but Java behaves the same against this server, so this is not a Rust client issue.
#### Overlaps and suggested merge order
Pairwise conflicts, checked with `git merge-tree` on the current PR heads:
| | #1381 | #1404 | #1407 | #1409 | #1411 |
|---|---|---|---|---|---|
| **#1381** | | `Cargo.toml`, `client.rs`, `simple_consumer.rs` | clean | `lib.rs`, `lite_subscription_manager.rs` | clean |
| **#1404** | | | clean | `push_consumer.rs` (1 hunk) | clean |
| **#1407** | | | | clean | clean\* |
| **#1409** | | | | | clean |
\* #1407 + #1411 merge cleanly as text, but the two tests added by #1411 then need the extra `filter_expression` argument introduced by #1407.
Suggested order:
1. **#1407.** It is small and merges cleanly with every other PR. LitePushConsumer is unusable on such servers without it.
2. **#1411.** It merges cleanly with every other PR. I will push the test fix-up right after #1407 lands.
3. **#1404**, then **#1381** rebased on it. These two conflict in `Cargo.toml`, `client.rs` and `simple_consumer.rs`.
4. **#1409**, which I will rebase onto #1404 and #1381:
- With #1404 there is a one-hunk conflict in the telemetry loop. The fix is to keep both `apply_settings` and the forwarding.
- With #1381 the logic overlaps. Both add a "wait for the initial `Settings`" signal to `LiteSubscriptionManager`. #1409 will reuse the one from #1381 and keep the Java behavior for LitePushConsumer, which is to fail `start()` on timeout (`ClientSessionImpl#settingsInitFuture`). #1381 currently logs a warning and continues for LiteSimpleConsumer. It may be worth aligning that as well.
Fixes for the remaining items (4a, 5, 10–12) will be opened as separate issue/PR pairs and linked here.
### Describe Alternatives You've Considered
One large PR with all the fixes. I decided against it because the fixes are independent and much easier to review one by one, and a single PR would conflict with #1381 and #1404 even more.
### Additional Context
- **Test setup.** About 60 scenarios across producer, LitePushConsumer subscribe / unsubscribe / offset options, ordering, retry, FIFO, quota, restart, multiple instances and shutdown. They ran against a managed RocketMQ 5 service, which pushes `lite_subscription_quota=2000`, `max_lite_topic_size=64`, `fifo=true` and `max_attempts=17`. Every finding above was compared with the Java client on the same server. I'm happy to contribute these scenarios towards #488.
- **Clippy on `master`.** With the current stable toolchain locally (rustc 1.98), `cargo clippy --all-features -- -D warnings` already fails on `master` with 2 `for_kv_map` errors in `rust/src/client.rs`. If CI's stable clippy is at that level, the Clippy job will be red on every Rust PR, independent of its content.
--
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: commits-unsubscribe@rocketmq.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6293050838
Update: added #1413 / #1414 (FIFO local retry now increases `MessageView::delivery_attempt`, aligned with Java `ProcessQueueImpl#eraseFifoMessage`). The PR table, the defect list (item 5), the conflict matrix and the suggested merge order above are updated. #1414 conflicts only with #1411 (resolution verified, see the matrix notes); I suggest merging it after #1407 and #1411 and will rebase it then.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6310886258
Update: item 16 (ack after `change_invisible_duration` silently ignored) now has #1430 / #1431.
- `SimpleConsumer::change_invisible_duration` writes the new receipt handle back into the `MessageView`, as Java `SimpleConsumerImpl#changeInvisibleDuration0` does. A later `ack` or change of the same view then takes effect. The public API is unchanged.
- End-to-end on the same server: on `master`, "change once / change twice, then ack the same view" returned `Ok` and the message was redelivered after ~40 s. With the PR it is not redelivered.
- It conflicts with #1427 in `simple_consumer.rs` (same function, plus tests appended at the same place). The resolution is described in the conflict table (§) and was verified on a temporary merge. It merges cleanly with every other open Rust PR. Since it changes a `pub(crate)` field type of `MessageView`, I also built and tested the merges with the PRs that use `MessageView`.
The table and the conflict matrix above are updated.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6306229611
Update: added #1418 / #1420 (item 11: `MessageBuilder::build()` rejects a blank lite topic, aligned with Java `setLiteTopic`) and #1419 / #1421 (item 10: strip `http://` / `https://` from a single-address access url, aligned with Java `Endpoints(String)`, so the official lite examples work). Both are single-file changes and merge cleanly with every PR in the matrix. Item 12 (a cosmetic WARN on start) will not be fixed.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6307625432
Update: two new issue/PR pairs, both based on #1404 and **to be merged after it**.
- **#1422 / #1423**: defect 4a. `PushConsumer` / `LitePushConsumer` `shutdown()` took 208.7 s with 6 queues (`master` + #1404 + #1381). Workers kept issuing long polls after shutdown started, because of an unbiased `select!` against a 1 ms ticker, and actors were shut down one by one. The fix checks shutdown first, like `ProcessQueueImpl` checks `consumer.isRunning()`, and shuts actors down concurrently, like `PushConsumerImpl#waitingReceiveRequestFinished`. End-to-end, shutdown takes about 5 s. **Depends on #1404 and #1381.**
- **#1424 / #1425**: new defect 13, found while testing #1423. In code added by #1404, `PushConsumer::apply_settings` sends the server `long_polling_timeout` (20 s) in the request, but the client deadline stays at the configured 40 s + 3 s. The fix also writes the shared value, as `SimpleConsumer` already does, so the deadline is 23 s like Java. With #1423 + #1425, all 6 end-to-end shutdown runs took 5.0 to 9.1 s; without #1425, 2 of 6 took about 28 s. **Depends on #1404.**
Each PR has one reviewable commit, touching `push_consumer.rs` only, on top of temporary merge commits of its dependencies. I will rebase both onto `master` once those are merged.
Also noted in the conflict matrix: #1404's latest push (`b5cb4940`) now conflicts with #1411 in `client.rs`, because both add `MTX.lock()` to `client_get_session`. It is trivial to resolve.
The body is updated (PR table, defects 4a and 13, conflicts, merge order). The only remaining item is 9, if it is still needed after #1404.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6314333044
Item 20: #1440 / #1441. `SimpleConsumer::receive` now only uses readable master queues and returns an error if there is none. New routes start round-robin at a random index. Both are aligned with Java `SubscriptionLoadBalancer`. On the real server, four fresh consumers used to all start at queue 0; with the PR they start at different queues. The filtering is covered by unit tests, because this server only exposes readable master queues.
The PR conflicts only with #1381 (and #1423 / #1435, which carry it); the resolution is in ♣. With this, every SimpleConsumer defect (14–21) has an open PR. The table above is updated.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6307860192
Update: item 9 is verified as fixed by #1404, so no separate PR is needed. All defects found by the end-to-end test are now covered:
- open PRs: #1407, #1409, #1411, #1414, #1416, #1420, #1421, #1423, #1425;
- covered by #1381 / #1404: items 2, 4b, 8 and 9;
- won't fix: item 12.
**Item 9.** The consumer was configured locally with `fifo=false`, and the server pushes `fifo=true`. On `master` + #1404 + #1381 (+ #1407, #1414, #1423, #1425), all queue actors start FIFO workers. A lite message that fails twice is delivered as attempt 1, 2, 3, and the next message of the same lite topic waits until it succeeds. Before, it was `F#1, F#1, N#1, F#3`. Details are in the body.
**CI.** The 3 red checks on the `master`-based Rust PRs all come from `master`:
- stable clippy `for_kv_map` in `client.rs`;
- the MSRV check, because `powerfmt v0.2.1` requires rustc 1.79;
- `build-result`, which only aggregates the two above.
They are not caused by those PRs. #1404 fixes both, so they should go green after it is merged and the PRs are rebased. Added to the body.
**Merge order is unchanged:** #1407 → #1411 → #1414 → #1404 → #1381 → #1409 / #1423 / #1425. #1416, #1420 and #1421 can go in at any point. The PRs are ready for review.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6311221253
Update: item 17 (SimpleConsumer keeps working after a failed `start()`) now has #1432 / #1433.
- `Client::start` rolls back when the first session can not be created. `SimpleConsumer::start` shuts the client down when the startup route lookup fails. `receive` / `ack` / `change_invisible_duration` fail with `ClientIsNotRunning` before any RPC. This is aligned with Java `SimpleConsumerImpl#startUp` and its `isRunning()` checks.
- End-to-end on the same server, after a failed start: on `master`, `receive` reconnected or long polled 20 s for `Ok([])`, and `ack` panicked in one case. With the PR, all three calls return `ClientIsNotRunning` within microseconds.
- It conflicts in `simple_consumer.rs` with #1381, #1427 and #1431 (same methods, tests appended at the same place). With #1404 it merges cleanly as text, but its new test needs a two-line adjustment. Resolutions are in the conflict table (¶); all were verified on temporary merges.
The table and the conflict matrix above are updated.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6313142717
Item 15: #1436 / #1437. `MessageView::born_timestamp()` / `delivery_timestamp()` now return milliseconds, as Java does. The response-level (transport) delivery timestamp is no longer copied into every message, so a normal message has no `delivery_timestamp()` and a delay message keeps its configured time. The producer also sends `born_timestamp` in milliseconds. This was verified end to end on a normal topic: master vs. this branch, with the Rust producer and consumer.
This changes the unit of two public getters without a compile error, so **maintainers, please confirm before merging**. One open question remains: `set_delivery_timestamp` still takes seconds (Java: milliseconds), and I left it unchanged on purpose (see #1436). The PR is based on `master` and is clean with every open Rust PR. The table above is updated.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6291487368
**Issue Evaluation**
Category: `type/bug` | Status: **Under Review**
This issue has been identified as a potential bug and is being analyzed.
---
*Automated evaluation by github-manager-bot*
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6310262621
Update: item 14 (received message body not decompressed, digest not verified) now has #1428 / #1429.
- It verifies the body digest and decompresses `GZIP`-encoded bodies, by magic number, so the ZLIB bodies that Remoting producers send (labelled `GZIP` by the proxy) are handled as well. It also adds `MessageView::is_corrupted()`. The PushConsumer nacks (standard) or dead-letters (FIFO) corrupted messages instead of calling the listener, as Java does.
- End-to-end on the same server: a 5090-byte message from the Remoting producer now arrives as the original text (before: 472 bytes of ZLIB), the same as with Java 5.2.2.
- It adds three small dependencies (`flate2`, `crc32fast`, `md-5`); they build with Rust 1.74.
- It has textual conflicts with #1411 and #1414 in `push_consumer.rs` (both sides append tests, plus one neighbouring line each). The resolution is described in the conflict table (‡) and was verified on temporary merges. It merges cleanly with every other open Rust PR.
The table and the conflict matrix above are updated.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6331018750
### How to merge (start here)
Merge from top to bottom. When a PR shows a conflict, wait: I rebase it, you don't need to resolve anything.
| # | PR | Fixes | Before merging |
|---|---|---|---|
| 1 | #1407 | LitePushConsumer receives nothing when the server decorates topic names (#1406) | Nothing. **Merge first.** |
| 2 | #1420 | Reject blank lite topic (#1418) | Nothing |
| 3 | #1421 | Accept `http://` / `https://` in the access URL (#1419) | Nothing |
| 4 | #1416 | Lite batch is silently lost (#1415) | Confirm the `batch_send` behavior change (see PR) |
| 5 | #1411 | Listener panic kills the consumer worker (#1410) | I push a small test fix after #1407 |
| 6 | #1414 | FIFO retry does not increase `delivery_attempt` (#1413) | I rebase onto #1411 |
| 7 | #1429 | Compressed body not decompressed (#1428) | I rebase onto #1411 + #1414 |
| 8 | #1404 | Telemetry session recovery (#1403), not mine | Its author resolves a one-line test conflict with #1411. **After this, master CI is green
again.** |
| 9 | #1381 | LiteSimpleConsumer, not mine | Its author rebases onto #1404 |
| 10 | #1425 | Receive deadline ignores server long polling timeout (#1424) | **Only after #1404.** I rebase to drop the temporary merge commit |
| 11 | #1423 | `shutdown()` takes minutes (#1422) | **Only after #1404 and #1381.** I rebase |
| 12 | #1409 | LitePushConsumer ignores server lite settings (#1408) | I rebase onto #1404 + #1381 |
| 13 | #1435 | LiteSimpleConsumer `suspend` (#1434) | **Only after #1381.** I rebase |
| 14 | #1427 | `receive` panics on bad arguments (#1426) | I rebase onto #1381 |
| 15 | #1431 | Ack after `change_invisible_duration` silently ignored (#1430) | I rebase onto #1427 |
| 16 | #1433 | Consumer keeps working after a failed `start()` (#1432) | I rebase |
| 17 | #1439 | `receipt_handle()` panics (#1438) | I rebase onto #1431 |
| 18 | #1441 | Unreadable / slave queues, always starts at queue 0 (#1440) | I rebase onto #1381 |
| — | #1437 | Timestamps in seconds (#1436) | **On hold:** needs your decision on the unit change. No conflicts, merge any time after |
- Rows 1–4 can be merged in any order, at any time.
- The only hard rule: rows 10–13 must not be merged before rows 8–9. They contain temporary merge commits of #1404 / #1381.
- The 3 red CI checks on rows 1–7 come from `master` (Clippy `for_kv_map`, MSRV) and go away after #1404 (row 8).
- Pairwise conflict details: see "Overlaps" below.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6293850399
Update: added #1415 / #1416 for item 6. Root cause is on the server side: the proxy returns one `SendResultEntry` per batch and the broker batch path does not dispatch lite messages to their lite topic (verified against the Java client, whose internal batch path fails on the receipt count mismatch). #1416 rejects multi-message lite batches before sending and, like Java `ProducerImpl#send0`, fails when the receipt count differs from the message count. **This is a breaking change for `batch_send`**: with such a proxy, any batch of more than one message now fails and callers should use `send` per message. #1416 only touches `producer.rs` and merges cleanly with every PR in the matrix, so it can go in at any point.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6309617450
Update: a second end-to-end round covered `SimpleConsumer`, on the same server with a normal topic and group, and Java 5.2.2 as a control. LiteSimpleConsumer could not be tested, because this server version rejects the `LITE_SIMPLE_CONSUMER` client type (Java fails in the same way).
It found 8 differences from Java, listed as items 14–21 in the new table above. The most serious ones:
- **18:** `receive_with(.., -1, ..)` panics, and `receive_with(.., 0, ..)` waits a full long poll. Fixed in #1427 (#1426).
- **14:** GZIP bodies are returned compressed.
- **16:** acking a `MessageView` after `change_invisible_duration` returns `Ok`, but the ack does not take effect.
- **15:** timestamps are in seconds instead of milliseconds. This changes public getters, so I will ask for a maintainer decision in its issue before changing anything.
I will fix the rest one at a time, each with its own issue and PR, and keep this table up to date.
#1427 touches `simple_consumer.rs` only. It merges cleanly with every open PR except #1381; the resolution for #1381 is described under the conflict matrix.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6312270994
Item 21: #1434 / #1435. `LiteSimpleConsumer::change_invisible_duration` of a lite message now sends `suspend=true`, as Java `ConsumerImpl#wrapChangeInvisibleDuration` does. This is code review only, because this server rejects `LITE_SIMPLE_CONSUMER`. The PR depends on #1381 (temporary merge commit, one reviewable commit) and adds no conflicts beyond those #1381 already has.
I deliberately did not apply this to the `LitePushConsumer` failure nack, although Java's standard consume service does. On a real server with local `fifo=false`, `suspend=true` kept the failing message at the same delivery attempt. It was redelivered every ~1.1 s together with the rest of its lite topic (114 times in 125 s) and never reached the DLQ. Maintainers, please confirm whether the push path should follow Java here. The details are in #1434 and #1435, and the table above is updated.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] [Rust] Tracking: PushConsumer / LitePushConsumer defects and related open issues and PRs [rocketmq-clients]
Posted by "leizhiyuan (via GitHub)" <gi...@apache.org>.
leizhiyuan commented on issue #1412:
URL: https://github.com/apache/rocketmq-clients/issues/1412#issuecomment-6313681916
Item 19: #1438 / #1439. `MessageView::receipt_handle()` now returns `""` instead of panicking when the message has no receipt handle, as Java does. For example, the message passed to the transaction checker has no handle. The PR is based on `master` and conflicts only with #1431, on the same line; the one-line resolution is in ♠. The table above is updated.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org