Skip to content

Comments

[1.17] Docs redis honor resiliency#5044

Open
cicoyle wants to merge 3 commits intodapr:v1.17from
cicoyle:feat-redis-honor-resiliency
Open

[1.17] Docs redis honor resiliency#5044
cicoyle wants to merge 3 commits intodapr:v1.17from
cicoyle:feat-redis-honor-resiliency

Conversation

@cicoyle
Copy link
Contributor

@cicoyle cicoyle commented Feb 19, 2026

docs for this PR noting how we honor resiliency policy now and not redis infinite redelivery

…olicy

Signed-off-by: Cassandra Coyle <cassie@diagrid.io>
@cicoyle cicoyle requested review from a team as code owners February 19, 2026 18:01
Copy link
Member

@msfussell msfussell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cicoyle - Left comments

## Resiliency and redelivery

The Redis Streams pubsub component honors the [Dapr resiliency policy]({{% ref "resiliency-overview" %}}). After your
application handler returns (success, error, RETRY, or DROP), the component acknowledges the message to Redis. Redis
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason some are CAPITALs and others are not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put RETRY and DROP capital bc they are explicit API status values from the PubSub API - see here: under the section titled Expected HTTP Response. I missed SUCCESS tho. I can update success to be capital for consistency, or I can lower then all if that is preferred. I used error as a general outcome rather than the status value.

The Redis Streams pubsub component honors the [Dapr resiliency policy]({{% ref "resiliency-overview" %}}). After your
application handler returns (success, error, RETRY, or DROP), the component acknowledges the message to Redis. Redis
then stops redelivering that message. Retries and dead-letter behavior are controlled by your resiliency policy (for
example, `maxRetries` and retry duration), not by Redis indefinitely.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does "not by Redis indefinitely" mean? Not sure what this is implying. Can you clarify

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before my code PR, when the handler returned an error or RETRY, the component did not ACK the msg to Redis and it was redelivered indefinitely regardless of the resiliency policy. Now, the component ACKs and honors the resiliency policy and does not redeliver indefinitely. I thought it was important to note that explicitly bc its a bug fix & change in behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ill just rm the last part of the sentence. this: not by Redis indefinitely. bc it will be implied bc it will follow the resiliency policy, then I think itll be good as-is.

@marcduiker marcduiker added this to the 1.17 milestone Feb 23, 2026
update based on feedback

Signed-off-by: Cassie Coyle <cassie.i.coyle@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants