vxcontrol/pentagi · warning

cookie claim invalid

Error message

cookie claim invalid

What it means

errCookieClaimInvalid signals that a session cookie was presented but is missing or has an invalid required claim (e.g. user id or user hash field absent/wrong type in the session). The middleware treats it as a routine auth failure rather than a server error: the request is rejected, typically with a 401, and the client should re-authenticate.

Source

Thrown at backend/pkg/server/auth/auth_middleware.go:110

// isRoutineAuthFailure reports whether authErr represents an expected,
// non-malicious session/token invalidation rather than a genuine application
// error, so callers can log it at a quieter level.
func isRoutineAuthFailure(authErr error) bool {
	return errors.Is(authErr, errCookieClaimInvalid) ||
		errors.Is(authErr, errSessionExpired) ||
		errors.Is(authErr, errUserHashMismatch)
}

// errCookieClaimInvalid is returned by tryUserCookieAuthentication when the
// session cookie is present but missing one or more required claims (expired
// or otherwise invalid session) - a routine, expected condition.
//
// errSessionExpired and errUserHashMismatch mark the same category of routine
// session/token invalidation, just detected a bit later during validation: a
// session past its TTL, or a stored hash that no longer matches the user
// record (e.g. after a password change or a test database reseed).
var (
	errCookieClaimInvalid = errors.New("cookie claim invalid")
	errSessionExpired     = errors.New("session expired")
	errUserHashMismatch   = errors.New("user hash mismatch")
)

func (p *AuthMiddleware) tryUserCookieAuthentication(c *gin.Context) (authResult, error) {
	sessionObject, exists := c.Get(sessions.DefaultKey)
	if !exists {
		return authResultSkip, errors.New("can't find session object")
	}

	session, ok := sessionObject.(sessions.Session)
	if !ok {
		return authResultFail, errors.New("not a session object")
	}

	uid := session.Get("uid")
	uhash := session.Get("uhash")
	rid := session.Get("rid")

View on GitHub (pinned to ea665308ba)

Solutions

  1. Clear the session cookie and log in again to get a fresh, valid session
  2. If it reproduces after login, verify the session store backend and its secret/key are consistent across instances
  3. After a server upgrade, bump/rotate sessions or accept that old cookies are invalidated and users must re-login

Example fix

// before
// client silently retries with the stale cookie
// after
axios.interceptors.response.use(null, (err) => {
  if (err.response?.status === 401) {
    window.location.href = '/login';
  }
  return Promise.reject(err);
});
Defensive patterns

Strategy: try-catch

Validate before calling

const hasSessionCookie = document.cookie.split(';').some(c => c.trim().startsWith('session='));

Try / catch

axios.interceptors.response.use(null, (err) => {
  if (err.response?.status === 401 && /cookie claim invalid|session/.test(JSON.stringify(err.response.data ?? ''))) {
    window.location.href = '/login';
  }
  return Promise.reject(err);
});

Prevention

When it happens

Trigger: A request arrives with a session cookie whose stored claims cannot be validated — cookie forged/corrupted, session data written by an older version with a different claim layout, or the cookie's user-id/hash values are not the expected types when read in tryUserCookieAuthentication.

Common situations: Server upgraded and session claim schema changed while old cookies persist in browsers; sessions store backend (cookie store) truncated or key rotated; user manually edited cookies; load balancer sends the request to an installation different from the one that issued the cookie.

Related errors

AI-assisted analysis of vxcontrol/pentagi@ea665308ba (2026-09-01). Data as JSON: /api/errors/350cc254a99cf961. Report an issue: GitHub.