Subversion Repositories SmartDukaan

Last modification

• Rev 37728 2026-09-21 12:18:41
• Author: amit

• Log message:

  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.