fix(go): prevent silent crash during concurrent WASM recovery

[fabriziodemaria]

Summary

• Serialize RecoveringResolver operations with a mutex so WASM instance recreation cannot close an instance while another resolve is still running on it.
• Perform recreation synchronously while the mutex is held, instead of swapping/closing in a background goroutine during concurrent pool resolves.
• Never cache or return nil WASM export handles; panic with a descriptive error so withRecover turns follow-on failures into evaluation errors instead of silent process death.

Motivation

When a WASM guest trap triggers recovery, the old wazero instance was closed in a background goroutine while another resolve on the same pooled slot could still be mid-call. Module.ExportedFunction on a closed instance returns nil, which was cached in fnCache and later dereferenced — producing exit code 139 with no Go traceback.

Test plan

• go test ./confidence/internal/local_resolver/... -run 'RecoveringResolver|ExportedFunction'
• go build ./...
• Deploy alongside interpreter-mode fix or independently and monitor temporal-worker SIGSEGV rate

Related

• Complements feat(go): add UseWasmInterpreter config for signal-safe WASM execution #514 (interpreter mode for SIGPROF/SIGURG during JIT execution)

Made with Cursor