Deleting DLQ Records

You can use the /openintegration/v1.0/dlq/messages/delete endpoint to mark a DLQ record as deleted.

Request:

• Method: POST
• Endpoint:

  https://<OI Host>:<OI
          Port>/openintegration/v1.0/dlq/messages/delete

• Description: This API marks a DLQ record as deleted by writing a delete marker to eps-dlq-state. The original DLQ Kafka record remains in the DLQ topic.
• Request body parameters:
  • dlqRecordId: Specifies the stable identifier of the DLQ record to delete. This parameter is required.
  • dlqTopic: Specifies the DLQ Kafka topic for the record. This parameter is recommended.

Response:

The response from the DLQ delete request can include the following fields:

Field	Description
deleted	Indicates whether the record is now considered deleted. A value of true includes records that were already deleted. A value of false means that no delete marker was written or applied.
found	Indicates whether EPS found the DLQ record or already had it marked deleted in the state cache. A value of false means that the requested dlqRecordId was not found or the request was invalid.
alreadyDeleted	Indicates whether a delete marker already existed before this request. When this value is true, the API does not write another marker.

The request can return the following response status codes:

• 200: Returned for deleted, already deleted, and not found outcomes. The response payload includes flags that describe the result.
• 400: The request contains malformed JSON, or dlqRecordId is missing, null, or empty.
• 401: The request is unauthenticated.
• 503: The state cache is initializing.
• 500: An unexpected runtime failure occurred.

Examples:

1. Sample Request:

   POST https://<OI Host>:<OI
             Port>/openintegration/v1.0/dlq/messages/delete

   Request Body:

   {
     "dlqRecordId": "testevent1-consumer1-dlq|consumer6|testevent1|2|6"
   }
   

   Response:

   {
     "dlqRecordId": "testevent1-consumer1-dlq|consumer6|testevent1|2|6",
     "dlqTopic": "testevent1-consumer1-dlq",
     "deleted": true,
     "found": true,
     "alreadyDeleted": false
   }
   

EPS Cache Behavior

EPS uses the following caches so that the REST APIs can fetch information with optimal latency:

• DLQ state cache: Stores deleted record IDs in a concurrent map.
• Metrics state cache: Stores aggregate counters in memory after replay.

Both caches initialize at startup. Other EPS operations, including DLQ operations, can continue while the caches initialize. However, the DLQ REST APIs must wait until cache initialization is complete. If a cache is still initializing, the API can return 503.