gofiber/fiber · warning

memory storage %s: %w

Error message

memory storage %s: %w

What it means

Returned by the in-memory storage adapter's *WithContext methods (GetWithContext, SetWithContext, DeleteWithContext, ResetWithContext) when the request context is already cancelled before the operation runs. wrapContextError checks ctx.Err() and wraps it with the operation name. This storage is primarily used in tests but mirrors the external storage contract.

Source

Thrown at internal/storage/memory/memory.go:243

	keys := make([][]byte, 0, len(s.db))
	for key, v := range s.db {
		// Filter out the expired keys
		if v.expiry == 0 || v.expiry > ts {
			keys = append(keys, []byte(key))
		}
	}

	// Double check if no valid keys were found
	if len(keys) == 0 {
		return nil, nil
	}

	return keys, nil
}

func wrapContextError(ctx context.Context, op string) error {
	if err := ctx.Err(); err != nil {
		return fmt.Errorf("memory storage %s: %w", op, err)
	}
	return nil
}

View on GitHub (pinned to 9a4c7e57fe)

Solutions

1. Use a detached context (context.Background) for storage writes that must complete even if the client disconnects.
2. Increase the request/server timeout if the storage op legitimately needs more time.
3. Check ctx.Err() before calling storage methods in latency-sensitive paths.
4. Handle context.Canceled / context.DeadlineExceeded explicitly and retry if appropriate.

Example fix

// before
storage.SetWithContext(c.Context(), key, data, 0)

// after
// use a detached context so the write completes after client disconnect
storeCtx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
storage.SetWithContext(storeCtx, key, data, 0)

// Check context before calling a *WithContext storage method
if ctx.Err() != nil {
    return fmt.Errorf("skip storage: %w", ctx.Err())
}

if err := storage.SetWithContext(ctx, key, data, exp); err != nil {
    if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) {
        // client gone; decide whether to finish with a detached context
    }
    return err
}

When it happens

Trigger: Calling storage.SetWithContext(ctx, ...) after ctx was already cancelled (context.Canceled) or its deadline passed (context.DeadlineExceeded). This surfaces in SaveFileToStorage flows where the request context expires before the store write, or in any code passing a request-scoped context to the memory store.

Common situations: Client disconnects mid-request causing the fiber context to cancel, a short request timeout firing during a slow storage op, or test code reusing an already-cancelled context.

Related errors

• file: failed to open file: %q: %w
• file: failed to read file: %q: %w
• file: failed to store file: %q to %q: %w
• context canceled while starting service %s: %w
• service %s start: %w

AI-assisted analysis of gofiber/fiber@9a4c7e57fe (2026-08-04). Data as JSON: /data/errors/1bff3a4d6cdc0c7b.json. Report an issue: GitHub.