d2modmaker-windows-amd64.exe stops responding to UI button clicks.

[Syllinger]

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.

[Syllinger]

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.

[Syllinger]

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.

[Syllinger]

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.