gohugoio/hugo · error
timeout
Error message
timeout
What it means
Returned by dispatcherPool.Execute (internal/warpc/warpc.go:247) when a single RPC to a WASM worker (katex, AVIF/WebP codec) gets no response within the hard-coded 30-second timer. The dispatcher gave up waiting on the call's done channel, meaning the WASM module is hung, overloaded, or its response was lost.
Source
Thrown at internal/warpc/warpc.go:247
if err != nil {
return d.zeroR, err
}
if err := d.send(call); err != nil {
return d.zeroR, err
}
timer := getTimer(30 * time.Second)
defer putTimer(timer)
select {
case call = <-call.donec:
case <-p.donec:
return d.zeroR, p.Err()
case <-ctx.Done():
return d.zeroR, ctx.Err()
case <-timer.C:
return d.zeroR, errors.New("timeout")
}
if call.err != nil {
return d.zeroR, call.err
}
resp, err := call.response, p.Err()
if err == nil && resp.Header.Err != "" {
err = errors.New(resp.Header.Err)
}
return resp, err
}
func (d *dispatcher[Q, R]) newCall(q Message[Q]) (*call[Q, R], error) {
if q.Header.ID == 0 {
q.Header.ID = d.id.Add(1)View on GitHub ↗ (pinned to 8a468df065)
Solutions
- Reduce the size of the offending asset (resize images before AVIF/WebP encode; split giant math expressions).
- Give the build more CPU or reduce build parallelism so each WASM call finishes within 30s.
- Retry the build — transient host load can cause one-off timeouts.
- If a specific reproducible input always times out, report it to Hugo (the 30s limit is not configurable).
Defensive patterns
Strategy: retry
Validate before calling
if timeout := cfg.Timeout; timeout < expectedWorstCase {
// raise the warpc timeout for large images/katex batches
} Try / catch
res, err := d.Execute(ctx, msg)
if err != nil && strings.Contains(err.Error(), "timeout") {
// retry once with a longer deadline; if it still times out, reduce input size
} Prevention
- Size the timeout to the largest asset you process, not the average
- Retry at most once — repeated timeouts mean the input is too large or the runtime is starved
- Split very large images/formula batches into smaller units
When it happens
Trigger: Any transform.ToMath (KaTeX), AVIF, or WebP encode/decode call where the Wasmtime-hosted module takes longer than 30s to reply — huge images, enormous formulas, a deadlocked module, or a machine under extreme CPU/memory pressure.
Common situations: Encoding very large images to WebP/AVIF on slow CI runners; heavily parallel builds starving the WASM workers; antivirus or cgroup CPU limits throttling wasmtime; pathological KaTeX input.
Related errors
- received invalid image dimensions: %dx%d stride %d
- decoded AVIF buffer size %d is not a multiple of frame size
- ErrShutdown
- received response for unknown call ID %d: WASM module violat
- invalid strict mode; expected one of error, ignore, or warn;
AI-assisted analysis of gohugoio/hugo@8a468df065 (2026-07-31).
Data as JSON: /data/errors/a1089741f3fe1297.json.
Report an issue: GitHub ↗.