From 88c9b7c2b8dd461068b44079ae01b12152715c24 Mon Sep 17 00:00:00 2001 From: BOHA Date: Sat, 6 Jun 2026 01:23:56 +0200 Subject: [PATCH] fix(auth): stop logging expected token expiry as an error MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit verifyAccessToken logged every invalid/expired access token via console.error with a full stack trace. Access tokens are ~15 min and the client silently refreshes + retries on the 401, so this is an expected condition that flooded production logs (~every 15 min per active user) and buried real errors. Now only genuinely unexpected failures (non-JsonWebTokenError, e.g. a DB error in loadAuthData) are logged. No behavior change — verification still returns null on any token error. Co-Authored-By: Claude Opus 4.8 (1M context) --- src/services/auth.ts | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/services/auth.ts b/src/services/auth.ts index 54ed06f..fd0c303 100644 --- a/src/services/auth.ts +++ b/src/services/auth.ts @@ -351,7 +351,17 @@ export async function verifyAccessToken( }) as unknown as JwtPayload; return loadAuthData(payload.sub); } catch (err) { - console.error("JWT verification error:", err); + // An expired or otherwise invalid access token is an EXPECTED condition: + // access tokens live ~15 min, and the client silently refreshes + retries + // on the resulting 401 (see src/admin/utils/api.ts). Logging every such + // case as an error — with a stack trace — floods the logs (roughly every + // 15 min per active user) and buries genuine errors. `JsonWebTokenError` + // is the base class of `TokenExpiredError`/`NotBeforeError`, so this skips + // all normal token-validation failures while still surfacing anything + // unexpected (e.g. a DB failure in loadAuthData). + if (!(err instanceof jwt.JsonWebTokenError)) { + console.error("Unexpected error verifying access token:", err); + } return null; } }