{ "schema_version": 2, "id": "commands/xclaim", "title": "XCLAIM", "url": "https://redis.io/docs/latest/commands/xclaim/", "summary": "Changes, or acquires, ownership of a message in a consumer group, as if the message was delivered a consumer group member.", "since": "5.0.0", "tags": [ "docs", "develop", "stack", "oss", "rs", "rc", "oss", "kubernetes", "clients" ], "last_updated": "2026-09-18T16:45:25+01:00", "page_type": "content", "content_hash": "69f00eedbe8c1b439a9e901a52386db20c0d17eb3cb202911d94241efd4dc7f4", "sections": [ { "id": "overview", "title": "Overview", "role": "overview", "text": "In the context of a stream consumer group, this command changes the ownership\nof a pending message, so that the new owner is the consumer specified as the\ncommand argument. Normally this is what happens:\n\n1. There is a stream with an associated consumer group.\n2. Some consumer A reads a message via [`XREADGROUP`](https://redis.io/docs/latest/commands/xreadgroup) from a stream, in the context of that consumer group.\n3. As a side effect a pending message entry is created in the Pending Entries List (PEL) of the consumer group: it means the message was delivered to a given consumer, but it was not yet acknowledged via [`XACK`](https://redis.io/docs/latest/commands/xack).\n4. Then suddenly that consumer fails forever.\n5. Other consumers may inspect the list of pending messages, that are stale for quite some time, using the [`XPENDING`](https://redis.io/docs/latest/commands/xpending) command. In order to continue processing such messages, they use `XCLAIM` to acquire the ownership of the message and continue. Consumers can also use the [`XAUTOCLAIM`](https://redis.io/docs/latest/commands/xautoclaim) command to automatically scan and claim stale pending messages.\n\nThis dynamic is clearly explained in the [Stream intro documentation](https://redis.io/docs/latest/develop/data-types/streams).\n\nNote that the message is claimed only if its idle time is greater than the minimum idle time we specify when calling `XCLAIM`. Because as a side effect `XCLAIM` will also reset the idle time (since this is a new attempt at processing the message), two consumers trying to claim a message at the same time will never both succeed: only one will successfully claim the message. This avoids that we process a given message multiple times in a trivial way (yet multiple processing is possible and unavoidable in the general case).\n\nMessages that have been released back to the group using [`XNACK`](https://redis.io/docs/latest/commands/xnack) are immediately claimable since their delivery time is set to 0, satisfying any minimum idle time requirement.\n\nMoreover, as a side effect, `XCLAIM` will increment the count of attempted deliveries of the message unless the `JUSTID` option has been specified (which only delivers the message ID, not the message itself). In this way messages that cannot be processed for some reason, for instance because the consumers crash attempting to process them, will start to have a larger counter and can be detected inside the system.\n\n`XCLAIM` will not claim a message in the following cases:\n\n1. The message doesn't exist in the group PEL (i.e. it was never read by any consumer)\n2. The message exists in the group PEL but not in the stream itself (i.e. the message was read but never acknowledged, and then was deleted from the stream, either by trimming or by [`XDEL`](https://redis.io/docs/latest/commands/xdel))\n\nIn both cases the reply will not contain a corresponding entry to that message (i.e. the length of the reply array may be smaller than the number of IDs provided to `XCLAIM`).\nIn the latter case, the message will also be deleted from the PEL in which it was found. This feature was introduced in Redis 7.0." }, { "id": "required-arguments", "title": "Required arguments", "role": "content", "text": "
key\n\nThe stream key.\n\n
\n\n
group\n\nThe consumer group name.\n\n
\n\n
consumer\n\nThe name of the consumer that will own the claimed messages.\n\n
\n\n
min-idle-time\n\nClaim only messages that have been idle for at least this long, in milliseconds.\n\n
\n\n
id [id ...]\n\nOne or more message IDs to claim.\n\n
" }, { "id": "optional-arguments", "title": "Optional arguments", "role": "parameters", "text": "Most of the following options are mainly for internal use, to transfer the effects of `XCLAIM` to the AOF file and replicas, and are unlikely to be useful to normal users.\n\n
IDLE ms\n\nSet the idle time (last time it was delivered) of the message. If `IDLE` is not specified, an idle time of `0` is assumed, that is, the time count is reset because the message now has a new owner trying to process it.\n\n
\n\n
TIME unix-time-milliseconds\n\nThe same as `IDLE` but sets the idle time to a specific Unix time (in milliseconds) instead of a relative amount of milliseconds. This is useful in order to rewrite the AOF file generating `XCLAIM` commands.\n\n
\n\n
RETRYCOUNT count\n\nSet the retry counter to the specified value. If not set, `XCLAIM` increments the retry counter every time a message is delivered again.\n\n
\n\n
FORCE\n\nCreate the pending message entry in the PEL even if the specified IDs are not already in the PEL assigned to a different client. However, the message must exist in the stream, otherwise the IDs of non-existing messages are ignored.\n\n
\n\n
JUSTID\n\nReturn just an array of IDs of messages successfully claimed, without returning the actual messages. Using this option means the retry counter is not incremented.\n\n
\n\n
LASTID lastid\n\nUpdate the consumer group's last-delivered ID to the given ID.\n\n
" }, { "id": "examples", "title": "Examples", "role": "example", "text": "[code example]\n\nIn the previous example, you claim the message with ID 1526569498055-0 and assign it to the consumer Alice, but only if neither the original consumer nor another consumer has acknowledged or claimed it for at least one hour." }, { "id": "redis-software-and-redis-cloud-compatibility", "title": "Redis Software and Redis Cloud compatibility", "role": "content", "text": "| Redis
Software | Redis
Cloud | Notes |\n|:----------------------|:-----------------|:------|\n| ✅ Standard
✅ Active-Active | ✅ Standard
✅ Active-Active | |" }, { "id": "return-information", "title": "Return information", "role": "returns", "text": "**RESP2:**\n\nAny of the following:\n* [Array reply](../../develop/reference/protocol-spec#arrays): when the _JUSTID_ option is specified, an array of IDs of messages successfully claimed.\n* [Array reply](../../develop/reference/protocol-spec#arrays): an array of stream entries, each of which contains an array of two elements, the entry ID and the entry data itself.\n\n**RESP3:**\n\nAny of the following:\n* [Array reply](../../develop/reference/protocol-spec#arrays): when the _JUSTID_ option is specified, an array of IDs of messages successfully claimed.\n* [Array reply](../../develop/reference/protocol-spec#arrays): an array of stream entries, each of which contains an array of two elements, the entry ID and the entry data itself." } ], "examples": [ { "id": "examples-ex0", "language": "plaintext", "code": "> XCLAIM mystream mygroup Alice 3600000 1526569498055-0\n1) 1) 1526569498055-0\n 2) 1) \"message\"\n 2) \"orange\"", "section_id": "examples" } ] }