d2modmaker
d2modmaker copied to clipboard
d2modmaker-windows-amd64.exe stops responding to UI button clicks.
My current flow has been to check/uncheck the Use Seed button to generate a new seed, Save, and then Run before starting a new game of Diablo 2.
I've noticed that, after running a few of these cycles, the d2modmaker-windows-amd64.exe
running in the console stops responding to button clicks in the UI. I've also noticed that, when clicking the Run button, the Success message defined in makeRunRequest
in Main.js
doesn't fire, but the almost identical saveConfig
function does. The only difference between the two appears to be that the former is an async
function, but I'm not sure why this would prevent the callback from firing. The post seems to work, as the console indicates that the call was logged, but the response in .then
is never handled.
To resolve this, I am required to close the console app and the browser, and restart. Also, anecdotally, it looks like this happens after 5 or 6 iterations, at which point the console app needs to be restarted.
EDIT: it appears to be after exactly 6 iterations that the web server no longer responds.
Did a bit more testing, and made some fetch
requests directly to the API endpoint. I was trying to confirm that the issue lies with the server, and not the UI. Sending API requests directly from the browser does seem to yield the same result; the server stops responding after 6 requests.
I did notice one peculiar thing during my testing: a response is never returned by the server when posting to /run
. Responses are returned by the /cfg
endpoint, and it appears that a response is expected as per the code in the makeRunRequest()
method in Main.js
. I'm wondering if, as a result, the server threads are being held open, and perhaps there can only be 6 open threads at any given time? Not sure about that one, someone more familiar with GO and the server implementation would need to confirm.
Output from the network tab. The calls to the /run
endpoint are left "pending" whereas any calls to /cfg
are resolved and issue a 200
status code. I've taken a look at the server code, and I'm not sure why the connection isn't closing, as there is a write block to update the status to 200 in run.go
.
I believe that I've identified the problem. When EnterToExit
is enabled (set to true
in cfg.json
), it's holding the connection open until the interrupt is received.
Since there is no way to update this flag in the UI, and the parsing code sets values for unspecified keys to their default values (as defined in the data
struct
), clicking the Save button will always set EnterToExit
to true
. The only way to modify this behaviour at present is to hard code it into cfg.json
and never hit the Save button in the UI (or you'll have to manually edit it again).
After testing with both Firefox and Chrome, my assumption is that the maximum number of concurrent open connections is enforced by the browser. During testing the console app would stop responding after 6 requests were made to the /run
endpoint when using Google Chrome, whereas the app wouldn't fail until 9 requests were made using Firefox.
@tlentz I understand that the UI is being re-written, but this will likely still be an issue.