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
- Use a large finite explicit timeout instead of NeverTimeout when targeting E2B
- Let the lifecycle coordinator pick a supported policy — do not force RemoteTimeoutPolicy{Mode: RemoteTimeoutExplicit, Value: -1} for E2B
- 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
- Never reuse Docker-style no-timeout policies for the E2B backend
- Centralize timeout-policy construction per backend so backend constraints are encoded once
- Prefer the lifecycle coordinator's supported policies over hand-built RemoteTimeoutPolicy values
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
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- E2B timeout must be at least one second
- e2b remote client config is required
- E2BAPIKey is required for the E2B backend
- sandbox: remote sandbox has no template configured
- timeout cannot be negative
AI-assisted analysis of Tencent/WeKnora@988cbb0330 (2026-09-02).
Data as JSON: /api/errors/0a7e5bcee9b3cd01.
Report an issue: GitHub.