{ "schema_version": 2, "id": "commands/rpoplpush", "title": "RPOPLPUSH", "url": "https://redis.io/docs/latest/commands/rpoplpush/", "summary": "Returns the last element of a list after removing and pushing it to another list. Deletes the list if the last element was popped.", "since": "1.2.0", "tags": [ "docs", "develop", "stack", "oss", "rs", "rc", "oss", "kubernetes", "clients" ], "last_updated": "2026-09-18T09:47:41+01:00", "page_type": "content", "content_hash": "7f5e84a14dfe1eb34985a9d7296e56fe91e9fd0667b0a046c68ee8bcff60ce05", "sections": [ { "id": "overview", "title": "Overview", "role": "overview", "text": "> [!NOTE]\n> This command's behavior varies in clustered Redis environments. See the [multi-key operations](https://redis.io/docs/latest/develop/using-commands/multi-key-operations) page for more information.\n\n\nAtomically returns and removes the last element (tail) of the list stored at\n`source`, and pushes the element at the first element (head) of the list stored\nat `destination`.\n\nFor example: consider `source` holding the list `a,b,c`, and `destination`\nholding the list `x,y,z`.\nExecuting `RPOPLPUSH` results in `source` holding `a,b` and `destination`\nholding `c,x,y,z`.\n\nIf `source` does not exist, the value `nil` is returned and no operation is\nperformed.\nIf `source` and `destination` are the same, the operation is equivalent to\nremoving the last element from the list and pushing it as first element of the\nlist, so it can be considered as a list rotation command." }, { "id": "required-arguments", "title": "Required arguments", "role": "content", "text": "
source\n\nThe key of the source list.\n\n
\n\n
destination\n\nThe key of the destination list.\n\n
" }, { "id": "examples", "title": "Examples", "role": "example", "text": "redis> RPUSH mylist \"one\"\n(integer) 1\nredis> RPUSH mylist \"two\"\n(integer) 2\nredis> RPUSH mylist \"three\"\n(integer) 3\nredis> RPOPLPUSH mylist myotherlist\n\"three\"\nredis> LRANGE mylist 0 -1\n1) \"one\"\n2) \"two\"\nredis> LRANGE myotherlist 0 -1\n1) \"three\"" }, { "id": "details", "title": "Details", "role": "content", "text": "" }, { "id": "pattern-reliable-queue", "title": "Pattern: reliable queue", "role": "content", "text": "Redis is often used as a messaging server to implement processing of background\njobs or other kinds of messaging tasks.\nA simple form of queue is often obtained pushing values into a list in the\nproducer side, and waiting for this values in the consumer side using [`RPOP`](https://redis.io/docs/latest/commands/rpop)\n(using polling), or [`BRPOP`](https://redis.io/docs/latest/commands/brpop) if the client is better served by a blocking\noperation.\n\nHowever in this context the obtained queue is not _reliable_ as messages can\nbe lost, for example in the case there is a network problem or if the consumer\ncrashes just after the message is received but before it can be processed.\n\n`RPOPLPUSH` (or [`BRPOPLPUSH`](https://redis.io/docs/latest/commands/brpoplpush) for the blocking variant) offers a way to avoid\nthis problem: the consumer fetches the message and at the same time pushes it\ninto a _processing_ list.\nIt will use the [`LREM`](https://redis.io/docs/latest/commands/lrem) command in order to remove the message from the\n_processing_ list once the message has been processed.\n\nAn additional client may monitor the _processing_ list for items that remain\nthere for too much time, pushing timed out items into the queue\nagain if needed." }, { "id": "pattern-circular-list", "title": "Pattern: circular list", "role": "content", "text": "Using `RPOPLPUSH` with the same source and destination key, a client can visit\nall the elements of an N-elements list, one after the other, in O(N) without\ntransferring the full list from the server to the client using a single [`LRANGE`](https://redis.io/docs/latest/commands/lrange)\noperation.\n\nThe above pattern works even if one or both of the following conditions occur:\n\n* There are multiple clients rotating the list: they'll fetch different \n elements, until all the elements of the list are visited, and the process \n restarts.\n* Other clients are actively pushing new items at the end of the list.\n\nThe above makes it very simple to implement a system where a set of items must\nbe processed by N workers continuously as fast as possible.\nAn example is a monitoring system that must check that a set of web sites are\nreachable, with the smallest delay possible, using a number of parallel workers.\n\nNote that this implementation of workers is trivially scalable and reliable,\nbecause even if a message is lost the item is still in the queue and will be\nprocessed at the next iteration." }, { "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 | Deprecated as of Redis v6.2.0. |" }, { "id": "return-information", "title": "Return information", "role": "returns", "text": "**RESP2:**\n\nOne of the following:\n* [Bulk string reply](../../develop/reference/protocol-spec#bulk-strings): the element being popped and pushed.\n* [Nil reply](../../develop/reference/protocol-spec#bulk-strings): if the source list is empty.\n\n**RESP3:**\n\nOne of the following:\n* [Bulk string reply](../../develop/reference/protocol-spec#bulk-strings): the element being popped and pushed.\n* [Null reply](../../develop/reference/protocol-spec#nulls): if the source list is empty." } ], "examples": [] }