The bug we only found by closing Forge and opening it again

Tonight’s work was about one thing: getting Forge into a state we’re actually comfortable handing to real testers, on machines that aren’t ours. Not “it passed the tests” comfortable — “we sat down and used it like a stranger would” comfortable.

That’s how we found today’s bug, and it’s a good example of the kind our own test suite structurally can’t catch.

What happened

Close Forge, then immediately click Launch again in Axonris Platform. Instead of opening, it says the module is already running — even though you just closed it. Wait a few seconds and try again, and it works fine. To a new user, that’s not a “wait a few seconds” message. That’s “this is broken, do I need to restart my computer.”

Why it actually happens

Forge doesn’t just vanish the instant you close its window. Its shutdown does real cleanup first — stopping a background sync thread, a research observer, and (if one was mid-run) a sandboxed code execution or a setup-verification process. Windows doesn’t kill child processes when a parent exits, so Forge has to wait for those explicitly before it’s safe to let the process end. That’s correct and deliberate — it’s what stops a sandboxed run from turning into an orphaned process still eating CPU five minutes later.

The problem was on the other side: Axonris Platform checks “is Forge’s process still alive?” the instant you click Launch. Right after closing, the answer is technically yes — Forge is still in the middle of that cleanup — and Platform took that as “this is already running, don’t start a second copy,” which is the right call for an actually-running Forge, but the wrong read on one that’s mid-close.

The fix

Platform now gives that a short, bounded window — about three seconds of quietly rechecking — before it decides anything is actually wrong. If Forge finishes closing in that window (which it almost always does), Launch just proceeds like nothing happened. If it’s genuinely still running after that — a real conflict, not a closing one — the message now says so plainly instead of implying you did something wrong.

We didn’t touch Forge’s shutdown sequence itself. It’s already correct; it was Platform’s zero-patience read of it that was wrong.

The rest of tonight, briefly

This came out of a wider pass through Forge using an actual populated project instead of the empty “nothing built yet” state every one of our checks normally starts from — that gap alone hid several small but real things: a “Welcome back” message that repeated itself right after Forge had already said something else, a roadmap that showed a warning icon on every item you hadn’t built yet (which is just… every project, at first), and a couple of error messages that blamed your code for problems that were actually on our end (a slow first-time process start, an outdated way of reading a package’s license).

None of these are dramatic. All of them are exactly the kind of thing that makes a first-time user quietly decide a tool isn’t for them, without ever filing a bug report about it.

Where that leaves things

The build with all of this is done and smoke-tested — it starts, it shows the right window, and it shuts down clean with nothing left running in the background. Before it’s something we hand to outside testers, we still want a fresh malware-scanner pass on the actual built file, purely as a sanity check on the build process itself, not because we found anything.

We’re not there yet. We’re closer than we were this morning, and closer in a way we can actually point to and explain — which is the only kind of “closer” worth posting about.