How to resolve "Already present: Duplicate request" Errors in YugabyteDB

In YugabyteDB, you may encounter an error like:

ERROR: Already present: [Already present (yb/consensus/retryable_requests.cc:488): Duplicate request 486166224 from client 4b0c1c99-8887-4925-a67b-6f8c67c92fd1 (min running 486166207)]

This error indicates that YugabyteDB has detected and blocked a duplicate write request from the same client. This safety mechanism prevents the same write operation from being applied more than once, which is crucial for maintaining consistency in distributed systems.

• When a client sends a write and, due to a network issue or timeout, retries the same request, the server may have already processed the original request.
• YugabyteDB tracks request IDs per client. If a request is retried with the same ID, the server recognizes it as a duplicate and rejects it with this error.
• This is most common during:
  • High-load or bulk operations (e.g., COPY, multi-threaded inserts)
  • Network partitions or node failures
  • Aggressive client-side retries
  • Timeout settings that are too low for the workload or hardware

• This error usually means the original request was already processed successfully, but the client did not receive a response (such as due to a timeout or failover).
• No data is lost—the error protects against writing the same data twice.
• In most cases, the data is safely in the database, and the error is informational.

• If you see this error rarely, it is safe to ignore for most use cases. Your data is consistent.

• Increase timeouts: Adjust flags such as retryable_rpc_single_call_timeout_ms to reduce unnecessary client retries, especially under heavy load or with slower disks.

• Review client retry logic: For DDLs and bulk operations, avoid automatic retries unless you are certain they are safe (see Issue #2012).

  Your application should have its own logic to handle transient errors like "Duplicate request". When this error occurs, it's often safe to assume that the previous batch either succeeded or is in the process of being committed. The application can be designed to continue with the next batch of data.

• For bulk loads (e.g., COPY): Use smaller transaction batches (rows_per_transaction) and/or increase timeouts.
• Check for software updates: YugabyteDB is actively improving error handling so users are not exposed to these internal errors. Review release notes and upgrade if fixes are available.

• If unsure whether your data was inserted, perform a SELECT to verify before retrying.

• If you encounter this error in unexpected scenarios or need specific guidance for your workload, please provide your operation details and environment when contacting support.
• Additional technical discussion and investigation details can be found in GitHub Issue #7251.

Reference: SUPPORT-637