v1.0.1-beta: fixing the first five seconds

Shipped v1.0.1-beta today, and it’s a release with a narrow, specific target: the first few seconds of a fresh install, before Chalie has even finished warming up. Everything else in the product can be exactly right and none of it matters if the very first thing a new user sees is a blank page.

Docker publishes the container port the moment the process starts, but Flask doesn’t bind to it until the end of boot — after the model warm-up imports, schema convergence, and startup migrations have all run. On slower hardware that gap is minutes, not seconds, and every connection attempt during it gets reset. Chrome shows ERR_CONNECTION_RESET; Safari, worse, describes it as an “access control check” failure, which reads like a security problem to a user who has no idea what’s actually happening. The fix: a stdlib-only holding screen that owns the port from the first instant of the process, serves a self-refreshing page that polls a /ready endpoint and reloads into the real app the moment it answers, and hands the port to the real server right before it binds. Fetch calls during that window get a clean {"ready": false} instead of a dropped connection. It shipped, then got reverted a few hours later, then came back — same idea, rebuilt as part of a combined hotfix once a second, related bug turned up.

That second bug was worse in a different way: it wasn’t a loading delay, it was a login that never resolved. The frontend’s auth gate — the guard that decides whether to send you to setup or straight into the app — was checking the router’s current route during the initial page load, but at that exact moment the current route is still Vue Router’s internal placeholder, not the page you’re actually headed to. Compare the wrong value and the !has_providers redirect retargets against itself forever: the guard fires the /auth/status check on every loop iteration, measured at roughly 100 requests a second, and the app never mounts. From the outside that’s just a blank screen that never becomes anything — no error, no spinner, nothing to click. The fix was a one-line comparison change, checking the intended destination route instead of the transient one, plus a rebuilt frontend bundle to actually ship it.

Both fixes landed together as a single hotfix commit, the version got bumped to 1.0.1-beta with a changelog entry, and the release went out same day. That’s the right shape for this kind of bug: cold-start failures don’t get partial credit for being diagnosed correctly — they only count once someone can actually reach the app. Verified against the shipped image directly: zero connection resets from process start, and the holding page keeps a user on the spinner until the app is genuinely ready, not just until the socket answers.

None of this is a new capability. It’s the opposite kind of work — making sure the capabilities that already exist are reachable by someone installing Chalie for the first time, on hardware you don’t control, without a debugger open. A release like this doesn’t move the roadmap forward, but it’s a precondition for every install that follows it actually landing somewhere real instead of bouncing off a blank page.

• Shipped v1.0.1-beta: a fresh-install-focused hotfix release, version bump and changelog same day

• Fixed cold-start connection resets: a stdlib-only holding page now owns the port from process start, self-refreshing until /ready answers, instead of every early request hitting a reset socket

• Fixed a login loop where the auth gate compared against Vue Router’s transient placeholder route instead of the intended destination, causing an infinite redirect and ~100 req/s of wasted auth checks

• Rebuilt and shipped the frontend bundle carrying the auth-gate fix

• Verified directly against the shipped image: zero connection resets from boot, clean handoff into the real app