logging: stop three non-defects reporting to the error board as ERROR
log4j2.xml ships ERROR and above to GlitchTip, so the log level IS the filter.
Three sources of ordinary, expected behaviour were logging at ERROR and between
them accounted for 51,244 events -- 43% of the whole board -- none of them a bug.
GlobalExceptionHandler already logs ProfitMandiBusinessException at WARN and is
unchanged; every leak below bypassed it.
1. Session state (27,302 events, 23% of the board). CookiesProcessor and the two
interceptors logged a missing or expired cookie at ERROR. A logged-out or
anonymous visitor is the normal case -- the code already handles it by
redirecting to /login or returning 403 -- and each of these sits in a class
whose surrounding lines already log at DEBUG. These never reach the handler,
which is why its WARN-level treatment never applied. Now DEBUG.
2. Client disconnect (19,349 events). There was no handler for it, so a client
hanging up mid-response fell through to @ExceptionHandler(Exception.class) and
was recorded as an unhandled server bug. Adds an IOException handler to both
GlobalExceptionHandlers that logs a disconnect at DEBUG and everything else at
ERROR with its 500 intact.
⚠ ClientAbortException CANNOT be imported here: catalina is provided by the
container and is not on either module's compileClasspath (verified against
the configuration, not assumed). The match is therefore on the simple class
name plus the "broken pipe"/"connection reset" messages, walked down the cause
chain. A genuine IOException matches none of those and keeps its ERROR.
The handler returns null for a disconnect rather than a body: the connection
that would carry it is already closed, and writing to it is what raised the
exception. Null is the supported way to say "handled, no body" --
HttpEntityMethodProcessor marks the request handled before reading the value.
3. Business exceptions re-logged at ERROR (11 sites). Each catches a
ProfitMandiBusinessException, logs it, and CONTINUES with a fallback -- a
missing wallet history defaults to an empty list, a user not found by primary
email is retried against the secondary. That is an expected outcome being
reported as a failure, and logging it at ERROR pre-empted the handler that
would have logged it at WARN. Now WARN.
Selenium/WebDriver (58,776 events) is deliberately untouched: that is a genuinely
broken ChromeDriver, and muting it would hide Oppo/Realme IMEI activation failing.
It looks like noise only because one broken thing repeated 52,000 times.