gofiber/fiber · warning

timeout or cancel

Error message

timeout or cancel

What it means

Returned by core.run when the request context's Done channel fires before either the response or the error channel delivers (client/core.go:136-145). It collapses two conditions — context cancellation and context timeout — into one sentinel because from the client's perspective both mean 'the caller no longer wants this request'.

Solutions

1. Lengthen or remove the context deadline if the operation legitimately needs more time.
2. Investigate upstream latency and fix the slow handler/proxy; the timeout is a symptom, not the root cause.
3. Make cancellation explicit — only cancel when you truly want to abort, and handle ErrTimeoutOrCancel as a normal outcome.
4. Distinguish timeout from cancel by wrapping: store your own timestamp to detect deadline-exceeded vs. manual cancel.

Example fix

// before
ctx, cancel := context.WithTimeout(ctx, 50*time.Millisecond)
resp, err := req.SetContext(ctx).Send() // ErrTimeoutOrCancel under load

// after
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
resp, err := req.SetContext(ctx).Send()

// Size the timeout to the upstream's observed p99 before sending
func timeoutFor(p99 time.Duration) time.Duration {
    return p99 * 3 // headroom
}

resp, err := req.SetContext(ctx).Send()
if errors.Is(err, fiber.ErrTimeoutOrCancel) {
    // distinguish: if ctx.Err() == context.DeadlineExceeded it was a timeout;
    // if ctx.Err() == context.Canceled it was an explicit cancel.
    switch ctx.Err() {
    case context.DeadlineExceeded:
        // retry with longer deadline or surface to caller
    case context.Canceled:
        // do not retry
    }
}

When it happens

Trigger: Calling request methods with a context that has a deadline (Request.SetContext(ctx) with ctx.WithTimeout/WithCancel) and the server does not respond before the deadline; explicit cancellation via cancel(); the client's own per-request timeout expiring through the context path.

Common situations: Tight request deadlines against a slow upstream; canceling in-flight requests on shutdown; using context.WithTimeout where the timeout is shorter than the upstream's p99 latency; a hung TCP connection that the context deadline reaps.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• client: HTTPS to HTTP redirect blocked
• context canceled while starting service
• only file paths and io.Writer are supported
• protocol not supported; only http or https are allowed
• service start

AI-assisted analysis of gofiber/fiber@a105acad6c (2026-08-11). Data as JSON: /api/errors/5f425627ef1ff451. Report an issue: GitHub.

Appendix: source

Thrown at client/core.go:300

	return ch
}

// releaseErrChan returns the error channel to the pool.
// It's caller's responsibility to ensure that:
// - the channel is not closed
// - the channel is drained before returning it
// - the channel is not reused after returning it
func releaseErrChan(ch chan error) {
	errChanPool.Put(ch)
}

// newCore returns a new core object.
func newCore() *core {
	return &core{}
}

var (
	ErrTimeoutOrCancel      = errors.New("timeout or cancel")
	ErrURLFormat            = errors.New("the URL is incorrect")
	ErrNotSupportSchema     = errors.New("protocol not supported; only http or https are allowed")
	ErrFileNoName           = errors.New("the file should have a name")
	ErrBodyType             = errors.New("the body type should be []byte")
	ErrNotSupportSaveMethod = errors.New("only file paths and io.Writer are supported")
	ErrBodyTypeNotSupported = errors.New("the body type is not supported")
)

View on GitHub (pinned to a105acad6c)