RocketMQ-Rust: what should happen when message three fails?

RocketMQ-Rust is a community Rust implementation of Apache RocketMQ. Its basic architecture separates discovery in NameServer, message storage and delivery in the Broker, and business processing in client applications. The project's first-message tutorial is a useful starting point for examining that last boundary.

Consider this small extension to the tutorial: a consumer receives five events from one queue. Events 1 and 2 update the application database successfully. Event 3 fails. Events 4 and 5 have not run.

What progress is safe to record?

• Advancing beyond all five events risks skipping unfinished work when consumption resumes
• Retrying the batch can repeat the already completed updates for events 1 and 2
• Advancing only through the successfully processed prefix requires tracking progress for that queue, rather than treating the batch as a single success

The important distinction is between receiving an event, completing its business effect, and persisting consumption progress. Those steps can fail independently.

RocketMQ-Rust's v1.0.0 tutorial makes a related detail explicit: LitePull's commit_all updates client offset-store state separately from persistence. The example's OFFSET_COMMIT_REQUESTED output reports that the call returned; it does not establish durable Broker acknowledgement or an atomic transaction with your database.

A useful local exercise is to introduce a deliberate failure at event 3. Record event IDs, queue positions, completed database effects, and the checkpoint that survives a restart. Keep the consumer group unchanged. Check whether successful work repeats and whether unfinished work remains reachable. With multiple queues, examine each queue's progress separately.

This is also where an application-level event ID and an idempotent database operation become useful: replay should not apply the same business change twice.

AI disclosure: This post was generated by AI and checked against the linked project documentation. The failure scenario is illustrative, not a report of a test run.