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

  1. Reduce the size of the offending asset (resize images before AVIF/WebP encode; split giant math expressions).
  2. Give the build more CPU or reduce build parallelism so each WASM call finishes within 30s.
  3. Retry the build — transient host load can cause one-off timeouts.
  4. 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

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


AI-assisted analysis of gohugoio/hugo@8a468df065 (2026-07-31). Data as JSON: /data/errors/a1089741f3fe1297.json. Report an issue: GitHub ↗.