`SUBSCRIBE` queued in `MULTI` makes `EXEC` fail halfway and leaves the transaction's key locked for every client
Maintainers usually reply within 2 days
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 57/100
Research direction
The report points to libs/server/Resp/PubSubCommands.cs:239, libs/server/Resp/RespServerSession.cs:745, and NetworkEXEC as relevant entry points. Read the RESP2 subscription-mode check and trace how EXEC replays queued commands while a transaction is running. Reproduce with the supplied MULTI, SUBSCRIBE, SET, EXEC sequence; done means EXEC completes, k is set to v, and other clients can use k immediately.
Written by the indexing model from the issue text.
Description
Describe the bug
When SUBSCRIBE is queued in a transaction, EXEC runs it and then rejects every later queued
command, and EXEC itself, with only (P|S)SUBSCRIBE / (P|S)UNSUBSCRIBE / PING / QUIT are allowed in this context. The transaction never commits. The queued SET is not applied, and the key stays
locked: other clients that read or write the key hang, even after the first client disconnects.
Other keys keep working.
Steps to reproduce the bug
docker run -d --name garnet -p 6379:6379 ghcr.io/microsoft/garnet:latest
printf 'MULTI\nSUBSCRIBE ch\nSET k v\nEXEC\n' | redis-cli -p 6379
# OK, QUEUED, QUEUED, then EXEC answers:
# 1) subscribe ch 1
# 2) ERR Can't execute 'SET': only (P|S)SUBSCRIBE / (P|S)UNSUBSCRIBE / PING / QUIT are allowed in this context
# followed by an extra reply: ERR Can't execute 'EXEC': ...
redis-cli -p 6379 SET k w # never returns
redis-cli -p 6379 GET k # never returns
redis-cli -p 6379 SET other w # OK
Expected behavior
As in Redis: EXEC answers 1) subscribe ch 1 2) OK, k holds v, and other clients can use
k right away. A transaction's locks should never outlive its EXEC, let alone its connection.
Screenshots
No response
Release version
v2.2.4
IDE
No response
OS version
Docker on Ubuntu 22.04 (x86_64); the container image is Ubuntu 24.04. (ghcr.io/microsoft/garnet:latest, 2026-10-27)
Additional context
Potential cause. EXEC replays the queued commands through the normal command loop while
txnManager.state == TxnState.Running. The replayed SUBSCRIBE sets isSubscriptionSession
(libs/server/Resp/PubSubCommands.cs:239), and the RESP2 subscription-mode check at
libs/server/Resp/RespServerSession.cs:745 runs before the transaction branch. So the check rejects
the rest of the queue and EXEC, and NetworkEXEC, the only place that commits and unlocks, is
never reached.
Suggested fix. Skip the subscription-mode check while a transaction is being replayed and for
EXEC/DISCARD, or reject SUBSCRIBE when it is queued in MULTI.
- Dominant language
- C#
- Stars
- 12.1k
- Forks
- 716
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 65
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/garnet
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 2 days
-
GEOADD updating a member's position keeps the member's old TTL, so the new position is silently deletedMay be free again @Saad-elnagar claimed this 9 days ago, and no pull request is open. Open
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
microsoft/garnet#2265 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 2 days
All issues in microsoft/garnet
Similar issues
-
bug effort:S P3
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
nightscout/nocturne#3093 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 3 days
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100