Tencent/WeKnora · error

E2B backend does not support NeverTimeout

Error message

E2B backend does not support NeverTimeout

What it means

E2B sandboxes always have a finite TTL, so a RemoteTimeoutPolicy of mode RemoteTimeoutExplicit carrying a negative value — the library's encoding of NeverTimeout — is unsupported and rejected by e2bTimeoutSeconds. The error tells the lifecycle coordinator to choose a different timeout policy or backend instead of issuing an impossible request.

Source

Thrown at internal/sandbox/e2b_remote_client.go:1101

		if value > 0 && value < time.Second {
			return 0, errors.New("E2B timeout must be at least one second")
		}
		seconds := value / time.Second
		if value%time.Second != 0 {
			seconds++
		}
		return int(seconds), nil
	}

	switch policy.Mode {
	case "", RemoteTimeoutServerDefault:
		if fallback <= 0 {
			return 0, nil
		}
		return toSeconds(fallback)
	case RemoteTimeoutExplicit:
		if policy.Value < 0 {
			return 0, errors.New("E2B backend does not support NeverTimeout")
		}
		return toSeconds(policy.Value)
	default:
		return 0, fmt.Errorf("unsupported timeout mode %q", policy.Mode)
	}
}

// toE2BVolumeMounts converts the provider-neutral RemoteVolumeMount slice to
// E2B SDK VolumeMount values. Nil and empty inputs both produce nil.
func toE2BVolumeMounts(src []RemoteVolumeMount) []e2b.VolumeMount {
	if len(src) == 0 {
		return nil
	}
	result := make([]e2b.VolumeMount, len(src))
	for i, mount := range src {
		result[i] = e2b.VolumeMount{
			Name: mount.Name,
			Path: mount.Path,

View on GitHub (pinned to 988cbb0330)

Solutions

  1. Use a large finite explicit timeout instead of NeverTimeout when targeting E2B
  2. Let the lifecycle coordinator pick a supported policy — do not force RemoteTimeoutPolicy{Mode: RemoteTimeoutExplicit, Value: -1} for E2B
  3. Switch to a backend that supports no-timeout (e.g. Docker) if unbounded lifetimes are required

Example fix

// before
policy := sandbox.RemoteTimeoutPolicy{Mode: sandbox.RemoteTimeoutExplicit, Value: -1} // never
// after
policy := sandbox.RemoteTimeoutPolicy{Mode: sandbox.RemoteTimeoutExplicit, Value: 24 * time.Hour}
Defensive patterns

Strategy: validation

Validate before calling

if policy.Mode == sandbox.RemoteTimeoutExplicit && policy.Value < 0 {
    // E2B cannot express NeverTimeout: substitute a large finite TTL
    policy.Value = 24 * time.Hour
}

Prevention

When it happens

Trigger: Mapping a RemoteTimeoutPolicy via e2bTimeoutSeconds (called from Create, Connect, Get, Delete, CreateSnapshot) where Mode is RemoteTimeoutExplicit and Value < 0 (the NeverTimeout encoding).

Common situations: A caller explicitly requests an immortal/never-expiring sandbox on E2B; a policy computed for the Docker backend (which supports no-timeout) is reused for E2B; config migration converts 'no timeout' into a negative explicit value.

Understand the failure class

Related errors


AI-assisted analysis of Tencent/WeKnora@988cbb0330 (2026-09-02). Data as JSON: /api/errors/0a7e5bcee9b3cd01. Report an issue: GitHub.