gofiber/fiber · warning

cache: failed to delete key %q: %w

Error message

cache: failed to delete key %q: %w

What it means

Thrown at middleware/cache/manager.go:201 by manager.del() when storage.DeleteWithContext fails. The cache middleware deletes keys during invalidation (e.g. when a cached response is stale beyond revalidation, or on explicit purge); a failure here means the storage backend rejected the DELETE.

Source

Thrown at middleware/cache/manager.go:201

// set data to storage or memory
func (m *manager) setRaw(ctx context.Context, key string, raw []byte, exp time.Duration) error {
	if m.storage != nil {
		if err := m.storage.SetWithContext(ctx, key, raw, exp); err != nil {
			return fmt.Errorf("cache: failed to store raw key %q: %w", m.logKey(key), err)
		}
		return nil
	}

	m.memory.Set(key, raw, exp)
	return nil
}

// delete data from storage or memory
func (m *manager) del(ctx context.Context, key string) error {
	if m.storage != nil {
		if err := m.storage.DeleteWithContext(ctx, key); err != nil {
			return fmt.Errorf("cache: failed to delete key %q: %w", m.logKey(key), err)
		}
		return nil
	}

	m.memory.Delete(key)
	return nil
}

func (m *manager) logKey(key string) string {
	if m.shouldRedactKeys {
		return redactedKey
	}
	return key
}

View on GitHub (pinned to 9a4c7e57fe)

Solutions

1. Check the wrapped error for the backend-specific cause and fix it (connectivity, ACLs, timeout).
2. Grant the storage user DELETE permission if it was scoped to read/write only.
3. Tune the storage driver timeout so deletes complete within the request lifetime.
4. Make cache invalidation best-effort: log the failure and let entries expire via TTL instead of failing the user request.
5. Verify storage connectivity with a health probe on a regular schedule.

Example fix

// before: invalidate failure bubbles up as 500
// (default error handler)

// after: log + degrade; TTL still bounds staleness
origHandler := app.ErrorHandler
app.ErrorHandler = func(c fiber.Ctx, err error) error {
    if strings.HasPrefix(err.Error(), "cache: failed to delete") {
        log.Printf("cache delete failed (TTL will reclaim): %v", err)
        return c.Next()
    }
    return origHandler(c, err)
}

// Confirm DELETE works at boot (some ACLs grant SET but not DELETE).
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
_ = store.SetWithContext(ctx, "__del_probe__", []byte("x"), time.Minute)
if err := store.DeleteWithContext(ctx, "__del_probe__"); err != nil {
    log.Fatalf("cache storage DELETE denied: %v", err)
}

if err := m.storage.DeleteWithContext(ctx, key); err != nil {
    // Best-effort: TTL will reclaim the entry anyway.
    log.Printf("cache delete failed for %q (TTL reclaims): %v", key, err)
    return nil
}

When it happens

Trigger: Cache invalidation path runs while Storage is unreachable, the connection timed out, or the request context was cancelled before the DELETE completed.

Common situations: Storage backend briefly down during an invalidate call; ctx cancellation; Redis in a read-only replica mode; ACL/permission mismatch where the app user lacks DELETE permission.

Related errors

• cache: failed to get key %q from storage: %w
• cache: failed to get raw key %q from storage: %w
• cache: failed to store key %q: %w
• cache: failed to store raw key %q: %w
• csrf: failed to fetch token from storage: %w

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