[Bugfix] WASM playground shows "Internal REPL Error" for every user error — traceback broken (missing _colorize) #392

New issue

Open

opened 2026-07-20 00:27:21 +00:00 by john · 0 comments

john commented

2026-07-20 00:27:21 +00:00

Owner

Found by the new #239 headless-browser test harness on its first run (part of #387).

Symptom

In the shipped web playground, any user code that raises — a syntax error (def bad(), a runtime error (1/0), an explicit raise — returns the string Internal REPL Error: Unknown error in capture code instead of the actual Python traceback. Non-raising code (1+1, print(...), object creation) works fine, and the interpreter recovers (subsequent evals succeed), so the bug is purely in error reporting. On desktop this path doesn't exist (ImGui REPL), so it's web-only and went unnoticed.

Root cause

run_python_string_with_output (src/platform/EmscriptenStubs.cpp) wraps user code in a capture harness whose exception branch does import traceback; traceback.format_exc(). On the web build:

>>> import traceback
ModuleNotFoundError: No module named '_colorize'

Python 3.13+ made traceback unconditionally import _colorize (Lib/traceback.py:13). The hand-curated WASM stdlib bundle wasm_stdlib/lib/python3.14/ (215 tracked files) includes traceback.py but not _colorize.py. So the wrapper's own error-formatting import raises, that exception propagates out of the capture code, and the C++ side reports the generic "Internal REPL Error".

_colorize.py only needs os, sys, collections.abc, dataclasses — all already bundled.

Fix

Primary: add _colorize.py to wasm_stdlib/lib/python3.14/ (copy from __lib/Python/Lib/_colorize.py). Rebuild playground, redeploy.
Secondary hardening (Fail-Early): the capture wrapper should degrade gracefully if traceback is ever unavailable — fall back to type(e).__name__ + ': ' + str(e) rather than turning every error into "Unknown error in capture code". A broken error-formatter shouldn't erase the error.

Regression coverage

tests/wasm/run_wasm_tests.py (#239) already asserts syntax- and runtime-error tracebacks surface (syntax_error_recovery, runtime_error_recovery). Those two cases are RED against the current build and go GREEN once _colorize is bundled — the harness is the regression test.

Found by the new #239 headless-browser test harness on its first run (part of #387). ## Symptom In the shipped web playground, **any** user code that raises — a syntax error (`def bad(`), a runtime error (`1/0`), an explicit `raise` — returns the string `Internal REPL Error: Unknown error in capture code` instead of the actual Python traceback. Non-raising code (`1+1`, `print(...)`, object creation) works fine, and the interpreter *recovers* (subsequent evals succeed), so the bug is purely in error *reporting*. On desktop this path doesn't exist (ImGui REPL), so it's web-only and went unnoticed. ## Root cause `run_python_string_with_output` (`src/platform/EmscriptenStubs.cpp`) wraps user code in a capture harness whose exception branch does `import traceback; traceback.format_exc()`. On the web build: ``` >>> import traceback ModuleNotFoundError: No module named '_colorize' ``` Python 3.13+ made `traceback` unconditionally `import _colorize` (`Lib/traceback.py:13`). The hand-curated WASM stdlib bundle `wasm_stdlib/lib/python3.14/` (215 tracked files) includes `traceback.py` but **not** `_colorize.py`. So the wrapper's own error-formatting import raises, that exception propagates out of the capture code, and the C++ side reports the generic "Internal REPL Error". `_colorize.py` only needs `os`, `sys`, `collections.abc`, `dataclasses` — all already bundled. ## Fix 1. **Primary:** add `_colorize.py` to `wasm_stdlib/lib/python3.14/` (copy from `__lib/Python/Lib/_colorize.py`). Rebuild playground, redeploy. 2. **Secondary hardening (Fail-Early):** the capture wrapper should degrade gracefully if `traceback` is ever unavailable — fall back to `type(e).__name__ + ': ' + str(e)` rather than turning every error into "Unknown error in capture code". A broken error-formatter shouldn't erase the error. ## Regression coverage `tests/wasm/run_wasm_tests.py` (#239) already asserts syntax- and runtime-error tracebacks surface (`syntax_error_recovery`, `runtime_error_recovery`). Those two cases are RED against the current build and go GREEN once `_colorize` is bundled — the harness is the regression test.