Improving B2C Order Automation with MQ Listener Integration and CI/CD Enhancements

From a code perspective, an order is a data flow; theoretically calling the order service API changes its status, but in practice physical goods create a coupling between online and offline processes, making order status dependent on the logistics flow.

In the B2C workflow, after a user places an order in the app, the order service calls the warehouse service to create a delivery order, the warehouse sends an MQ message upon successful shipment, and only then does the order status change to "shipped"; after logistics confirms receipt, the status becomes "transaction successful".

When the test scenarios were integrated into the company’s CI/CD platform (Beetle), various failures appeared, categorized into product issues, service node problems, environment constraints (e.g., thread‑pool limits, Nginx timeout), test case flaws (short wait times, strict assertions), and other anomalies such as merged outbound orders.

The most stubborn problem involved outbound orders: after payment, goods remain at the warehouse, requiring packaging, appointment, and verification steps; if multiple orders share the same address, phone, or recipient, they may be merged, leading to nondeterministic status. The team mitigated this by using unique addresses per test case and extending wait times, which increased total execution time from over 900 seconds to more than 2000 seconds but still resulted in many partial passes.

To break this deadlock, the team discovered that the middle‑platform service missed MQ messages, causing sales orders to stall. By employing RocketMQ’s PullConsumer mode, they added an MQ listening action to test cases: during execution, the test pulls messages from the relevant topic/tag within the past three minutes, proceeds if assertions pass, or stores failure details in Redis for later handling.

A scheduled task (zzschedule) runs every two minutes, scans Redis keys prefixed with mqPending__ , retrieves the stored information, and pulls the corresponding MQ messages. Adjustments were made to handle offset edge cases when a topic has sparse messages, ensuring the correct beginOffset is used.

The MQ listening action can also serve as a long‑wait mechanism: a test can send a delayed MQ message (e.g., 10 minutes) and wait for it, avoiding thread‑blocking Sleep calls.

After incorporating the MQ listener and enabling concurrent test execution, the overall success rate of the test suite rose dramatically, allowing the project to progress to the next phase.