Description
The WASM goroutine in cmd/gh-aw-wasm/main.go:48 has no recover(). A panic inside doCompile will leave the JavaScript Promise permanently unresolved (browser hang) and crash the WASM instance. All other goroutines in the codebase already have explicit recover() — this is the single gap.
Suggested Changes
Wrap the goroutine body with a deferred recover that calls reject.Invoke(Error(fmt.Sprint(r))) so the browser Promise resolves with an error instead of hanging.
Files Affected
cmd/gh-aw-wasm/main.go (line 48)
Success Criteria
- Runtime panics inside
doCompile call reject with the error message instead of leaving the Promise pending
- WASM instance survives panics without crashing the whole runtime
- All existing WASM tests pass
Priority
High — any nil-pointer or index-out-of-bounds inside compile silently hangs the browser UI
Source
Extracted from Repository Quality Improvement Report - Goroutine Lifecycle Hygiene #47586
🔍 Task mining by Discussion Task Miner - Code Quality Improvement Agent · sonnet46 · 42.2 AIC · ⌖ 5.29 AIC · ⊞ 7.1K · ◷
Description
The WASM goroutine in
cmd/gh-aw-wasm/main.go:48has norecover(). A panic insidedoCompilewill leave the JavaScript Promise permanently unresolved (browser hang) and crash the WASM instance. All other goroutines in the codebase already have explicitrecover()— this is the single gap.Suggested Changes
Wrap the goroutine body with a deferred recover that calls
reject.Invoke(Error(fmt.Sprint(r)))so the browser Promise resolves with an error instead of hanging.Files Affected
cmd/gh-aw-wasm/main.go(line 48)Success Criteria
doCompilecallrejectwith the error message instead of leaving the Promise pendingPriority
High — any nil-pointer or index-out-of-bounds inside compile silently hangs the browser UI
Source
Extracted from Repository Quality Improvement Report - Goroutine Lifecycle Hygiene #47586