POST /api/admin/xfer/cancel/v1

Note

This page was generated by extracting information from a JSON Schema data file for the API. It may be missing some information, or otherwise suggest approximate or placeholder values based on information in the schema file; this is due to limitations on how that data is extracted from the underlying Rust code and into the JSON Schema, and then again from there and into these docs.

Allows the system operator to stop a message transfer that was previously initiated via the /api/admin/xfer/v1 API endpoint. The cancellation works by walking the xfer scheduled queue, reversing the metadata changes made as part of setting up the xfer (to restore the original scheduling information) and then re-inserting the message into an appropriate scheduled queue. The cancellation is "instantaneous" in the sense that it applies just once to the specified xfer scheduled queue. Any other messages that are in-flight or imminently about to be reinserted into that scheduled queue will not be considered, so you may need to trigger the cancellation a few times over short time span to ensure that all messages are taken out of the xfer queue.

Cancellation requests always complete asynchronously because they may operate on very large quantities of messages, and it is infeasible to wait for completion in the context of a single HTTP request.

Request Body

The request body is required.

The Content-Type header must be set to application/json.

This is an object value, with the following properties:

• queue_name - required string. The name of the xfer scheduled queue

• reason - required string. Reason to log in the delivery log. Each matching message will log with an AdminRebind record to indicate that it was moved from its containing queue, and this reason will be included in that record.

Examples

{
  "queue_name": "string",
  "reason": "Scaling down"
}

Responses

Status 200

Xfer added successfully

Content-Type: application/json

This is an object value, with no properties.

Examples

{}