← Community
bugfixed

Studio server aborts on startup with UnicodeEncodeError when stdout is redirected (Windows)

Muhammad Akif JanjuaMuhammad Akif Janjua#414d ago · 57 views
fixed in: station-v0.93

On Windows, studio_server.py prints ✓/✗ glyphs during startup — before it binds its port — with no stdout-encoding guard. When the server's stdout isn't a real console (redirected to a log or pipe, or run under a service/scheduler), the default cp1252 encoding can't encode those glyphs and the process crashes before it ever starts serving.

Observed

The module-load summary prints Unicode glyphs, unguarded:

for m in _MODULES_STATE["loaded"]:
print(f" ✓ {m['id']} v{m['version']} · ...")
for m in _MODULES_STATE["rejected"]:
print(f" ✗ {m['slug']}: {m['reason']}")

(studio_server.py L7264, L7267; there's a → at L3414 too.)

cp1252 — the default Windows encoding when stdout is redirected — raises UnicodeEncodeError on ✓ (U+2713), ✗ (U+2717), and → (U+2192).

studio_server.py never reconfigures stdout. The CLI does: railcall_cli.py L38-44 runs sys.stdout.reconfigure(encoding="utf-8", errors="replace") with the comment "prevent cp1252 UnicodeEncodeErrors." That fix was never applied to the server.

railcall studio launches the server as a fresh subprocess (subprocess.call([sys.executable, server], ...)), so it does NOT inherit the CLI's reconfigure, and no PYTHONIOENCODING is set.

Why it's a startup failure, not cosmetic

The glyph print (L7264) runs BEFORE the server is constructed (srv = _Srv((HOST, PORT), H) at L7380) and before srv.serve_forever() (L7449), and it isn't wrapped in try/except. So when the encode raises, execution aborts before the port is ever bound — the server doesn't come up.

When it fires (Inferred)

Real interactive terminal: modern Python gives the Windows console a UTF-8 writer, so the glyphs encode and startup succeeds. This is the common case, so most users never see it.

Redirected / piped / captured stdout, or under a service/scheduler/CI: sys.stdout.encoding is cp1252 -> the print raises -> the server never starts.

Suggested fix (one line, already present in the sibling file)

try:
sys.stdout.reconfigure(encoding="utf-8", errors="replace")
sys.stderr.reconfigure(encoding="utf-8", errors="replace")
except AttributeError:
pass

...or replace the glyphs with ASCII markers ([ok] / [x]).

Environment: station-v0.78, Windows 10. Verified from source plus a stdlib encoding check ('✓'.encode('cp1252') raises). A running instance survives when launched attached to a real console (UTF-8) — which is exactly why this is easy to miss.

3 pts

1 reply

Fixed in station-v0.93, @akif.janjua.123. Your trace was complete — glyph prints before the port binds, no reconfigure, and the CLI's own cp1252 guard never inherited because the server is a fresh subprocess. The same sys.stdout.reconfigure(encoding="utf-8", errors="replace") guard now runs at studio_server module top, before any local import can print, on stdout and stderr, with errors="replace" so an exotic locale degrades a glyph rather than the boot. Regression test runs a real subprocess under PYTHONIOENCODING=cp1252 with redirected stdout — the no-guard control crashes with UnicodeEncodeError, the guarded path boots. Credited.

Sign in to reply.