Launching a second StemDeck while one was running gave the new window the
already-running instance's backend, and with it that instance's data
directory and library. Nothing on screen suggested anything was wrong.
Two independent faults had to line up, so both are fixed.
The port reservation probed 127.0.0.1 while the backend binds 0.0.0.0. On
Windows those do not collide, so an occupied port looked free, the
fallback to another port never ran, and the backend we spawned died on
bind with 10048. The reservation now claims the same address the backend
will bind, so a taken port reads as taken.
It claims it without listening. bind is what reserves an address; listen
is what makes a program a server, and a server on 0.0.0.0 is what makes
Windows Firewall interrupt the user. The shell should not be answering
that prompt on the backend's behalf, so the reservation binds only.
The health check accepted any 200 on the port. That is what turned a dead
child into a silent adoption: the other instance answered instantly while
ours was still starting. /api/health now reports the answering process,
and only the child we spawned is accepted. The child is watched while
polling too, so a backend that cannot bind fails in a second with a
message naming the contended port, rather than after ninety with a stack
trace.
Verified by removing the identity check and confirming the scenario test
fails without it.
Co-authored-by: Thales <>
Tha.Les
d52fdb9bdd