A Lightweight Mock/Spy Tool for Data Consistency in RPC Timeout Scenarios

This article examines the problem of data inconsistency that arises when RPC calls experience network timeouts, particularly in cases where the interface is non‑idempotent or idempotency breaks, making it difficult to determine whether the remote operation ultimately succeeded.

It first describes the three possible network states—success, failure, and timeout—and explains why timeout scenarios are the most complex for ensuring eventual data consistency across distributed services.

The author proposes a lightweight "pseudo‑idempotent" tool that can mock or spy on service calls regardless of the transport protocol (JSF, WebService, HTTP, or in‑process method calls). The tool can be configured to return predefined results, effectively "pre‑paying" success to the caller while optionally allowing the real method to execute.

Configuration is expressed as JSON, allowing multiple rule entries, each specifying the target class, method, time window, and strategy. Two strategies are supported: DO_NOTHING_AND_RETURN_SPECIFIED_VALUE (mock only) and DO_AND_RETURN_SUCCESS_REGARDLESS_OF_FAILURE (execute then mock). An example configuration is shown below:

{
  "detailList": [
    {
      "enabled": true,
      "className": "com.jdwl.wms.stock.app.service.main.StockTransferAppServiceImpl",
      "methodName": "increaseStock",
      "basicNo1": null,
      "basicNo2": null,
      "basicNo3": "6_6_601",
      "uuidList": null,
      "businessNoList": ["GZQ202503160250001"],
      "startTime": "2025-03-16 01:50:00",
      "endTime": "2025-03-18 03:50:00",
      "strategy": "DO_NOTHING_AND_RETURN_SPECIFIED_VALUE",
      "defaultResult": {
        "resultValue": true,
        "resultCode": 100000,
        "prompType": 0,
        "success": true
      }
    }
  ]
}

The article then details the implementation steps, including how the tool matches request parameters against the configured range, decides which strategy to apply, and returns the mock result.

Two practical cases are presented:

Case 1 demonstrates mocking a service call via DUCC configuration, confirming that the method is not executed and the predefined result is returned.

Case 2 shows how the tool blocks the generation of abnormal data during a stock‑taking operation, effectively preventing erroneous inventory reservations.

Both cases verify the tool’s effectiveness through database checks and log analysis, showing that it can quickly restore data consistency without requiring full distributed‑transaction mechanisms.

In conclusion, the lightweight mock/spy utility provides a pragmatic approach for handling non‑idempotent or idempotency‑failed RPC calls in timeout scenarios, offering a fast‑track solution for data correction, recovery, and even read‑service mocking, while acknowledging its current limitations and targeted use cases.