Redis v2

Provides integration with Redis, an in-memory data store that applications use as a cache, a message broker and a lightweight queue. Its Pub/Sub channels deliver messages to every connected subscriber, and its lists hold ordered values that producers push onto and consumers pop from.

The Node can publish messages to a channel, push values onto a list, pop values from a list, and start a Workflow for each message published to a channel or each value added to a list. Use it to exchange events with applications that already use Redis, or to use a Redis list as a simple work queue between systems. It works with any Redis-compatible server, such as Redis, Valkey, Redis Cloud, Azure Cache for Redis and Amazon ElastiCache.

Revision History

0.0.0.2 - Initial release.

Connection

The Connection stores the server address and credentials. All Methods use it.

Setup Notes

This Node supports Cloud and Local Runtimes. Use a Local Runtime for servers that are only reachable on your network.

1. Find your server's host name and port. Redis Cloud, Azure Cache for Redis and ElastiCache show these on the database or cache overview page.
2. Build the ConnectionString, for example myhost:6380,password=...,ssl=true. Add ssl=true when the server requires TLS. For ACL users, such as Redis Cloud database users, add user= and password=.
3. Test the Connection. The test connects and sends PING, so wrong addresses, rejected credentials and TLS problems surface before a Workflow runs.

Counted pops are most efficient on Redis 6.2 or later. On older servers the Node pops one value per command instead.

Methods

The Node exposes three Connector Methods and two Trigger Methods. Messages and values are exact strings: the Node does not trim, parse or re-serialize them.

Each Method connects and checks the server while it starts, so connection, authentication and TLS failures fail the step immediately. The first publish, the first push batch, the first pop and the channel subscription also run before the Node returns its results.

Publish Messages

Publishes one message per input row to a Redis Pub/Sub channel.

SubscriberCount is the number of subscribers that received the message. Publishing to a channel with no subscribers succeeds with SubscriberCount 0.

The Flowgear object contains:

• IsSuccess: whether the message was published.
• Message: a success message, or the reason the message failed.
• Request: the input row.

Push Items

Pushes one value per input row onto a Redis list. The Node sends up to 100 values per command.

ListLength is the length of the list after the batch that contained the row, so every successful row in a batch reports the same value.

The Flowgear object contains:

• IsSuccess: whether the value was pushed.
• Message: a success message, or the reason the value failed.
• Request: the input row.

Pop Items

Removes and returns values from a Redis list.

The Node pops up to 100 values per command until it reaches MaximumItems or the list is empty. An empty or missing list returns no rows. If a later pop fails, the Node returns the values it has already removed and then stops with the error.

Listen Channel

Starts the Workflow for each message published to a Redis channel. Use this trigger when the Workflow should run as messages arrive until it is stopped.

Listen List

Polls a Redis list and starts the Workflow for each value removed from it. Use this trigger when the Workflow should run as values are added until it is stopped.

The Node pops up to 100 values per command. After a full batch of 100 it polls again immediately; after a shorter batch, which means the list is drained, it waits PollIntervalSeconds. It retries quietly after lost connections and timeouts, and stops when Redis rejects the command, for example with WRONGTYPE or NOPERM.

Usage Notes

• For a first-in, first-out queue, push with Side Left and pop with Side Right. For a last-in, first-out stack, push and pop with Side Right.
• Message and Value fields in Items must be JSON strings. To send an object, convert it to JSON text first.
• Publish Messages and Push Items read the first Items row before connecting. If the first row has no Message or Value string, the step fails. When Items is empty, the Node returns no rows and does not connect. It still rejects a missing or malformed ConnectionString, but an unreachable server or wrong credentials are not reported in that case.
• After the first message or batch, a later row returns a failed row and the Node continues with the next row when the row has no Message or Value string, when Redis rejects the command (for example with WRONGTYPE), or when the command times out. A lost connection stops the Node, including a timeout that occurs while the client is disconnected. A push batch is one command, so when Redis rejects a batch or it times out, every row in that batch fails together.
• A timeout means Redis may or may not have applied the command. A timed-out row reports IsSuccess false even if the message was delivered or the value was pushed, so sending failed rows again can create duplicates.
• Pops remove values before the Workflow processes them. If a later step fails, those values are gone, so delivery is at most once. If the Workflow stops reading rows, for example when a run is aborted, up to 100 values that were popped but not yet returned are lost.
• Redis Pub/Sub does not store messages. Anything published while Listen Channel is not subscribed, including during reconnects, is lost. Use a list with Listen List when every message must be processed.
• The Node never retries publish, push or pop commands, so a dropped connection cannot duplicate a message or lose popped values to a retry.
• Error messages never include the ConnectionString password.

Known Issues

• Pattern subscriptions (PSUBSCRIBE), sharded Pub/Sub and reliable queues (LMOVE) are not supported.
• After Listen List has started, it can't tell a lost connection from rejected credentials, because the client reports both as a timed-out poll. If the password is changed or the ACL user is removed while the listener runs, it keeps retrying without an error and processes nothing until you fix the Connection or restart the Workflow. Restarting with the wrong credentials fails immediately.
• Listen Channel holds received messages in memory until the Workflow processes them, with no size limit. A slow Workflow on a very busy channel uses more memory over time.

See also

• StackExchange.Redis configuration
• Redis Pub/Sub
• Create a Connection