A tester (kubiix) installed the Windows x64 NSIS build of v1.4.0 and reported that after a long wait the app window opens on a webview error page saying the connection to http://localhost:34115 failed. That page means the bundled Node server never started listening: the launcher waits 90 seconds for the port and then opens the window regardless.
The 1.4.0 shell discarded the server's stdout/stderr, so the report carries no diagnostics. The next release changes that: the launcher writes everything the server prints to server.log in the app data directory (%APPDATA%\com.apocdev.pyops\server.log on Windows), fails fast when the server process dies instead of burning the full timeout, and replaces the raw webview error with a diagnostic page that shows the log path and keeps polling so a slow first launch recovers into the app on its own.
Next step is getting that build to the tester and reading the log. Suspects if it still reproduces:
- Antivirus interfering with (or slow-scanning) the unsigned node.exe sidecar — a slow first boot past the 90 s window would now self-heal.
- \?\ extended-length resource paths from Tauri's resolver — the next release strips these with dunce before handing them to the sidecar.
- A native-module failure (better-sqlite3/sharp) in the bundled server — the log will show the stack trace directly.
Close when the tester confirms a working launch on Windows, or when the log identifies a concrete bug to split out.
A tester (kubiix) installed the Windows x64 NSIS build of v1.4.0 and reported that after a long wait the app window opens on a webview error page saying the connection to http://localhost:34115 failed. That page means the bundled Node server never started listening: the launcher waits 90 seconds for the port and then opens the window regardless.
The 1.4.0 shell discarded the server's stdout/stderr, so the report carries no diagnostics. The next release changes that: the launcher writes everything the server prints to server.log in the app data directory (%APPDATA%\com.apocdev.pyops\server.log on Windows), fails fast when the server process dies instead of burning the full timeout, and replaces the raw webview error with a diagnostic page that shows the log path and keeps polling so a slow first launch recovers into the app on its own.
Next step is getting that build to the tester and reading the log. Suspects if it still reproduces:
Close when the tester confirms a working launch on Windows, or when the log identifies a concrete bug to split out.