Expired keys still affect type checks, SETNX and DEL
Maintainers usually reply within 2 days
@TedHartMS is already working on this.
Since Oct 15, 2026.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 62/100
Research direction
Start by running the redis-cli script from the report against a local Garnet instance on port 6379 to confirm LLEN returns WRONGTYPE, DEL returns 1 and SETNX returns 0 on expired keys. The payload does not name source files, so locate the expiration check the key lookup uses and see why these three commands skip it. Done means LLEN returns 0, DEL returns 0 and SETNX returns 1 for the expired keys, matching Redis.
Written by the indexing model from the issue text.
Description
Describe the bug
Expired keys are still treated as present by LLEN, DEL and SETNX after their TTL has elapsed.
Steps to reproduce the bug
On a local test instance at port 6379, with redis-cli:
k="upstream-repro-$(date +%s)-$$"
r() { redis-cli -p 6379 "$@"; }
r SET "$k:s" v PX 10
sleep 0.1
r LLEN "$k:s" # actual: WRONGTYPE
r SET "$k:d" v PX 10
sleep 0.1
r DEL "$k:d" # actual: 1
r RPUSH "$k:l" a
r PEXPIRE "$k:l" 10
sleep 0.1
r SETNX "$k:l" v # actual: 0
Expected behavior
Expected LLEN 0, DEL 0 and SETNX 1, as in Redis.
Screenshots
No response
Release version
Garnet main at 44cf0bdb7d36 (reports 2.2.1).
IDE
No response
OS version
Linux arm64
Additional context
No response
- Dominant language
- C#
- Stars
- 12k
- Forks
- 711
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 56
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
-
HINCRBY wraps on int64 overflow and stores the resultPossibly taken @TedHartMS claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
microsoft/garnet#2243 · 1 assignee ·
Maintainers usually reply within 2 days
-
An integer argument >= 2^64 returns "ERR Protocol Error" and closes the connection (INCRBY, PEXPIRE, LRANGE, LINDEX, …)Possibly taken @TedHartMS claimed this today. Open
microsoft/garnet#2249 · 1 assignee ·
Maintainers usually reply within 2 days
-
INCR rejects a stored INT64_MIN valuePossibly taken @TedHartMS claimed this today. Open
Difficulty 3/5 1-2 days Newbie friendliness 62/100
microsoft/garnet#2246 · 1 assignee ·
Maintainers usually reply within 2 days
-
Large PEXPIRE closes the connection without a replyPossibly taken @TedHartMS claimed this today. Open
Difficulty 3/5 1-2 days Newbie friendliness 62/100
microsoft/garnet#2245 · 1 assignee ·
Maintainers usually reply within 2 days
-
2.2.1: SAVE fails - main index checkpoint buffer only 512-byte aligned on 4096-sector device (NativeStorageDevice misaligned I/O)Possibly taken @TedHartMS claimed this 2 days ago. Open
microsoft/garnet#2239 · 2 comments · 1 assignee ·
Maintainers usually reply within 2 days
All issues in microsoft/garnet
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Sector-Vestige/Sector-Vestige#476 ·
Maintainers usually reply within 1 day
-
S: Untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Trauma-Station/Trauma-Station#5058 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
HoffmanEngineering/3d-print-log-api#243 ·
Maintainers usually reply within 1 day
-
:books: documentation untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 1 day