preston-peterson/aerodrome v3.4.49

on GitHub

No single slow page can freeze the rest of the interface anymore. v3.4.48 fixed this for the Watchlist and Military data endpoints, but the same underlying issue affected most of the app: the Logs, Stats, Documentation, Search, and other endpoints all ran their database and file work directly on the web server's single event loop, so whenever any one of them was busy on a large install, every other request — page navigation, health checks, other tabs — had to wait in line behind it. A capture on the reference install showed the Logs endpoints taking 66 seconds, Stats 34 seconds, and the Documentation page 38 seconds, each of which froze everything else for its full duration. v3.4.49 moves every handler that does blocking work into the web server's worker threadpool, so the event loop stays free to service other requests no matter what any one endpoint is doing. Navigating the gear menu and switching tabs stays responsive even while a heavy page is still loading its own data.

Behind the scenes

• The change converts 81 route handlers from asynchronous to synchronous definitions. A handler declared async but which never actually awaits anything gains nothing from being asynchronous — it still runs to completion on the event loop without ever yielding, so any slow work inside it blocks every other request. The web framework runs synchronous handlers in a worker threadpool instead, which is exactly where blocking database and file work belongs. The seven handlers that genuinely do asynchronous work (file uploads, config import, the GitHub-apply and backup-restore flows) were left asynchronous, as they should be.
• This was identified the same way as the v3.4.48 fix: the per-section response timing added in v3.4.47 showed /api/status calls whose own handler work was single-digit milliseconds nonetheless taking 25-35 seconds of wall time, which is only possible if they were queued behind something else holding the loop. Each capture pointed at a different slow endpoint, confirming the problem was the shared-loop architecture rather than any one query.
• The individual heavy endpoints (Logs, Stats, Watchlist, Military) are still slow on their own at very large scale — moving them off the shared loop stops them blocking each other but doesn't make their own queries faster. Reducing those queries is tracked as follow-up work; this release is the architectural fix that makes the app usable in the meantime.
• The v3.4.47 diagnostic timing fields are retained one more release to confirm this fix from a capture (the expected result: no endpoint shows other requests queued behind it). They'll be removed alongside the heavy-query optimizations.

Operational notes

• No schema changes, no config changes, no migration. The change is handler declarations switching from async to synchronous; request/response behavior and shapes are unchanged.
• Expected behavior after deploy: the gear menu, dashboard, and tab switching stay responsive at all times. Individual data-heavy tabs (Logs, Stats, Watchlist, Military) may still take time to load their own content on very large installs, but loading one no longer blocks the others.