Skip to content

feat(keyspace): emit set and del notifications#3541

Open
Aetherance wants to merge 6 commits into
apache:unstablefrom
Aetherance:feat/notify-keyspace-events
Open

feat(keyspace): emit set and del notifications#3541
Aetherance wants to merge 6 commits into
apache:unstablefrom
Aetherance:feat/notify-keyspace-events

Conversation

@Aetherance

@Aetherance Aetherance commented Jul 1, 2026

Copy link
Copy Markdown

Implement keyspace notifications for SET and DEL, compatible with Redis notify-keyspace-events.

This PR adds the initial notification emitters and configuration support:

  • Support K, E, g, $, and A flags, where A currently expands to the implemented event classes g$.
  • Emit set notifications only when SET actually applies a write, including conditional SET variants.
  • Emit del notifications only for keys that are actually deleted.
  • Deduplicate repeated keys in a single DEL, so DEL a a deletes and notifies once.
  • Queue notifications inside MULTI/EXEC and publish them after a successful commit.
  • Map notification DB names correctly:
    • default namespace uses DB 0
    • redis-databases namespaces map back to Redis DB indexes

This PR only adds notification emitters on primary nodes for SET and DEL, keeping the initial patch small and reviewable. Replica-side notifications and additional commands, if supported, can be added in follow-up PRs.

Unsupported notification classes are rejected for now until their emitters are implemented.

Ref Proposal: #3533
Tracking Issue: #2915

Assisted by Codex/GPT-5.5.

@Aetherance

Copy link
Copy Markdown
Author

I added optional output parameters to String::Set and Database::MDel so the command layer can emit notifications based on what actually changed.

For SET, this avoids duplicating the conditional SET decision logic in the command layer. For DEL, this avoids an extra EXISTS pass before deletion, which would add unnecessary storage reads and overhead. It also lets MDel return the keys it actually deleted.

The alternative would be to keep these storage APIs unchanged and infer the notification decisions in the command layer. That would keep the APIs smaller, but the trade-off is that SET would duplicate conditional SET/GET logic outside String::Set, and DEL would need extra reads before MDel. Over time, this could also drift from the actual write behavior.

I chose the optional-output approach for this PR, but I’m open to maintainers’ preference here.

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.

2 participants