fix(lua.core): prevent concurrent request in lua server

[jerem-ai]

During an automated run (balatrobot v1.5.1, Balatro v1.0.1n, Windows, serve --headless --fast), a pack JSON-RPC call arriving while the pack area was empty/closing crashed the whole game process:

[SMODS balatrobot "src/lua/endpoints/pack.lua"]:127: attempt to index field 'cards' (a nil value)

Repro (from our logs): open a booster pack, then issue pack with a card index after the pack area has emptied (race under high gamespeed — our client polled state, the pack closed between the read and the call). Expected: a typed INVALID_STATE/BAD_REQUEST error response. Actual: unhandled Lua error → 'Oops! The game crashed' → process exit, taking the JSON-RPC server with it.

Suggested fix: guard the pack-area access in pack.lua (~line 127) and return INVALID_STATE when the area is nil/empty.

Context: we run thousands of automated runs against the API (great framework, thank you!) — we've worked around it client-side by never sending pack when our last-seen pack area is empty, but the unguarded path can still be hit by any client racing the animation.

[S1M0N38]

thanks for the report. I'm currently working on the version v2 of balatrobot (see dev branch). I'm trying to set up a better logging and replay feature to replicate these kind of issues. Sometimes there are a bit hard to debug (race condition, weird combo, animations, etc...) so as you pointed out the best way make the these issue pop up is to stress test the balatrobot framework.

I will look into this issue.

(btw if you can share somehow the full log when this issue occurred it will be pretty useful - double check that your are not sharing any sensitive inforamtion)

[S1M0N38]

Concurrent pack requests crash the game process

Description

Sending two pack requests at the same time for an Arcana (or Spectral) pack causes the game process to crash. The server becomes unresponsive and all subsequent requests fail. The crash is deterministic when both requests pass target validation.

Steps to Reproduce

1. Start a run: start({"deck": "RED", "stake": "WHITE", "seed": "BUG193_CRASH"})
2. Select a blind: select()
3. Set chips high to auto-win: set({"chips": 1000000, "money": 500})
4. Play a hand: play({"cards": [0, 1, 2, 3, 4]})
5. Cash out to reach the shop: cash_out()
6. Add an Arcana pack: add({"key": "p_arcana_normal_1"})
7. Buy the pack: buy({"pack": 0})
8. Send two pack requests concurrently (5ms apart), both targeting card index 0: pack({"card": 0, "targets": [0]})

A reproduction script is provided (script.py).

Expected Behavior

Both requests should be handled gracefully. The second request should either return an error ("pack is no longer available") or wait and succeed after the first completes.

Actual Behavior

Both requests return empty responses (0 bytes). The game process crashes and the server is permanently dead. All subsequent requests fail with connection errors.

Environment

• OS: macOS
• Lovely version: 0.8.0
• SMODS version: v1.0.0~BETA-1221a
• BalatroBot commit: 084044e

Note

The crash only triggers when both requests pass target validation (i.e., the card's target requirements match the targets parameter). Seeds where the first pack card requires exactly 1 target work reliably. Seed BUG193_CRASH produces such a configuration.

Files

• 60084.log
• 60084.req.jsonl.txt
• 60084.res.jsonl.txt
• script.py

[S1M0N38]

I've tried to reproduce the issue my self in the dev branch. @jerem-ai you can ignore that long message about the issue reproduction (it's just for my clanker).

[S1M0N38]

I thought this was a problem related to the pack endpoint but it turns out that is was a more subtle bug. If a endpoint take more than one frame to process a race condition can occur. The HTTP server running in the mod was accepting and processing new connection while the previous was still open. The simple fix was to check if a client_socket as already active before accepting new connections

if not BB_SERVER.client_socket then
  BB_SERVER.accept()
end

I think this was the root of this very issue and prolly the root of other hidden race conditions.
btw I think that we cannot rely to have the listen(0) and have to use listen(1) in order to be compatible with various systems (linux, macos, windows), so that simple if should be enough.

I keep this issue closed cuz the commit in 1.5.2 fix the bug I was able to reproduce. If you find new bug related to this (or not) feel free to open a new issue.

[jerem-ai]

Confirmed — deployed v1.5.2 today under our harness (paired-seed batches, hundreds of runs queued over the next few days). We also hit a related-looking wedge pre-1.5.2 where a non-empty booster pack returned NOT_ALLOWED to every pack call indefinitely (seed K9VIGG3R, Red deck / White stake) — consistent with your corrupted-accept theory, since the server otherwise stayed responsive. Will open a new issue with request/response logs if it recurs on 1.5.2. Thanks for the fast turnaround.