[cosmin-staicu]

Redis Streams consumers poll every PollInterval (250 ms) even when the Pub/Sub doorbell already wakes them on each write. Idle, that is about 15 server-executed commands per second per topic per process.

RedisStreamsTopicOptions.NotifiedPollInterval is the poll cadence while the doorbell subscription is confirmed live. PollInterval stays the cadence whenever it is not: before the first subscribe, after a reconnect until the topic subscribes again, while the subscription connection is down, when the server refuses the subscription, and with NotifyEnabled off. Losing the doorbell ends a wait already in progress at the long interval. Failure retries and the XINFO GROUPS position check stay on PollInterval.

Unset, it is 5 s when PollInterval was not set, and PollInterval when it was, so an app that configured PollInterval keeps its cadence. A PollInterval key in configuration counts as set even at 250 ms, and a global one counts for every topic; options bound through AddRedisStreams(sectionName) and the per-topic sections keep an absent key unset. An explicit value must be positive and at least PollInterval.

The doorbell reads as down only for the subscription connections that failed, tracked per endpoint, and comes back with the last of them; a failure that lands while a subscribe completes keeps it down. PollInterval must now be positive.

Why 5 s

Measured per process with 3 topics, single Redis, loopback:

NotifiedPollInterval	idle server commands/s	vs 250 ms	visibility, doorbell on (p50)	stale window if one doorbell message is lost (max)
250 ms	44.4	–	6 ms	0.23 s
1 s	12.0	−73%	14 ms	0.96 s
2 s	6.0	−86%	12 ms	2.0 s
5 s	2.4	−95%	14 ms	4.6 s
10 s	1.2	−97%	14 ms	9.5 s
30 s	0.38	−99%	24 ms	28.6 s

The saving per extra second of worst-case staleness drops from 6.0 commands/s (1 → 2 s) to 1.4 (2 → 5 s) and 0.24 (5 → 10 s). The worst case only applies to a message dropped while the subscription still looks live; every outage the library can detect falls back to PollInterval. Events are lost only above MaxLength / interval per second per topic, about 6 500/s at 5 s with the default MaxLength.

Tests

• Unit: each row of the default rule, clones, configuration with and without the key, per-topic overrides; subscription-only connection tracking and the subscribe race; the waiter's interval switch (including a long wait cut short), the channel's live/not-live transitions (before subscribe, failure, restore with and without the subscription, forced reconnect, refused, dispose), the writer's wait choice, validation and Clone.
• Redis integration: a lost doorbell with a live subscription, doorbell off, refused subscription.

[github-actions]

🔎 Maintainer heads-up: automated triage flagged this PR as potentially material, so it may need a signed CLA in addition to the DCO sign-off.

Strong signals

• adds public API surface (PublicAPI.Unshipped.txt in src/UiPath.Caching)

This is advisory only — the bot does not decide. Please judge against the CLA criteria (material, product-critical, patent-sensitive, corporate contributor, broad commercial use). Note that thresholds can be gamed by splitting PRs, so use your judgement.

• If a CLA is needed → add the cla-required label (a contributor comment with signing steps is posted automatically).
• If it is not needed → replace needs-cla-review with cla-not-required so later pushes don't re-flag it.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
98.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud