Publishes nothing
Event classes selected with no channel to publish them on, which is silent
A
Enter a notify-keyspace-events value to see exactly which events it publishes and on which channels. Both the bare flag string and the whole config line are accepted.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Decode. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Event classes selected with no channel to publish them on, which is silent
A
What KEA actually covers, and the two event types it leaves out
notify-keyspace-events "KEA"
A narrow selection, with the warning that expired events are not a timer
Ex
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
A selects event classes but no channel, so nothing is ever published. The configuration is valid and accepted, and the result is total silence with nothing to debug.
Instead:Add K or E, or both. `KEA` is the usual value.
A expands to g$lshzxetd and deliberately excludes `n` for new-key and `m` for key-miss events, because both are very high volume.
Instead:Add `m` or `n` explicitly, after checking what volume that means for your workload.
The event fires when the key is actually removed, lazily on access or via a sampling cycle, not when the TTL passes. A key nobody touches can wait a long time.
Instead:A sorted set keyed by expiry that you poll gives you control over the precision.
They are ordinary pub/sub. A message published while no subscriber is connected is discarded, with no buffer, no replay and no acknowledgement.
Instead:Use a stream with a consumer group, which has both acknowledgement and replay.
The value is a string of single-character flags with no separator, and it fails silently in two specific ways that produce no error and no events.
K selects __keyspace@<db>__:<key> channels, where the channel names the key and the message is the event. E selects __keyevent@<db>__:<event> channels, where the channel names the event and the message is the key. Setting event classes without either produces total silence, and notify-keyspace-events A is the most common way to do it.
A expands to g$lshzxetd, deliberately excluding n for new-key events and m for key-miss events, both because they are very high volume. Anyone who set A expecting key-miss events receives none and has nothing to debug, because the configuration is valid and accepted.
The expired event fires when the key is actually removed, not when its TTL passes. Removal happens either lazily on the next access or via a sampling cycle running ten times a second over a subset of keys with TTLs. A key nobody touches can wait a noticeable time for its event, so this is not a scheduler.
These are ordinary pub/sub messages. A message published while no subscriber is connected is discarded, with no buffer, no replay and no acknowledgement. Any disconnection is silent data loss for the consumer, which makes notifications unsuitable for anything that must not be missed. A stream with a consumer group has acknowledgement and replay.
It decodes the flag string. It cannot tell you whether a subscriber exists, whether it keeps up, or what volume your workload would produce. Enabling A on a write-heavy instance can publish more messages than the workload itself, and the cost falls on the same single thread serving commands.