Lua scripts ignore SELECT and always run against database 0
Maintainers usually reply within 2 days
@kevin-montrose is already working on this.
Since Oct 20, 2026.
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
Research direction
Start at Garnet's EVAL and EVALSHA handling and trace how Lua commands select the database for Redis calls. Reproduce with the issue's SELECT 1 sequence, with LuaTransactionMode both on and off. Done means scripts read and write database 1 after SELECT 1, matching plain commands and Redis behavior.
Written by the indexing model from the issue text.
Description
After SELECT 1, EVAL and EVALSHA still read and write database 0. Plain commands on the same connection use database 1 as expected.
Repro against a fresh GarnetServer 2.2.3 (win-x64 release zip) with EnableLua: true and MaxDatabases: 16, same result with LuaTransactionMode on or off:
SELECT 1 -> OK
SET k from-db1 -> OK
GET k -> "from-db1"
EVAL "return redis.call('get', KEYS[1])" 1 k -> (nil) expected "from-db1"
EVALSHA <sha of the same script> 1 k -> (nil) expected "from-db1"
EVAL "return redis.call('set', KEYS[1], 'from-lua')" 1 k2 -> OK
GET k2 -> (nil) expected "from-lua"
SELECT 0
GET k2 -> "from-lua" the script wrote to database 0
On Redis the script runs in the connection's selected database, so both reads return from-db1 and k2 lands in database 1.
This breaks libraries that keep their keys in another database and use Lua, for example a distributed lock (Medallion.Threading.Redis extends and releases its lock with Lua scripts) on a GetDatabase(1): the scripts never find the lock key.
- Dominant language
- C#
- Stars
- 12.1k
- Forks
- 716
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 69
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
-
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 7 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 1-2 days Newbie friendliness 57/100
Maintainers usually reply within 2 days
-
TsavoriteLog fast-commit recovery adopts a stale suffix after recovering and reusing the tailPossibly taken @TedHartMS claimed this 2 days ago. Open
Difficulty 5/5 Over a week Newbie friendliness 25/100
microsoft/garnet#2299 · 1 reaction · 1 assignee ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
Maintainers usually reply within 2 days
-
INCR rejects a stored INT64_MIN valuePossibly taken @TedHartMS claimed this 13 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 62/100
microsoft/garnet#2246 · 1 assignee ·
Maintainers usually reply within 2 days
All issues in microsoft/garnet
Similar issues
-
area-ai bug untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
dotnet/extensions#7893 ·
Maintainers usually reply within 1 day
-
devtools documentation
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
area-System.ComponentModel untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
dotnet/runtime#136608 · 2 comments ·
Maintainers usually reply within 1 day
-
fix: Cannot reopen dialog after closing with escape key in FluentDialogPossibly taken @bryan-ramirez claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
microsoft/fluentui-blazor#5572 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sillsdev/languageforge-lexbox#2846 ·
Maintainers usually reply within 1 day