Sentry noise: user/operator-input validation logged as errors (ANTHIAS-1P/1R/1X/1S/1Z/2A)

[vpetersson]

A cluster of post-deploy Sentry events are not bugs — they're user input or operator-config conditions logged at error level (so the logging integration turns them into events), the same noise class already filtered for redis/CancelledError/GitHub:

• ANTHIAS-1P / 1R / 1X — AuthSettingsError from /settings/save/ ("password too short", "must supply current password"). Operator typed an invalid password; this should be a 400/form error to the user, not a Sentry error. (logger=anthias_server.app.views, "Settings save failed")
• ANTHIAS-1S / 1Z — operator-config warnings captured as errors: "auth_basic enabled but credentials …", "Insecure password hash … clearing credentials". Legit operator-facing log lines, but error-level → Sentry. Downgrade to warning.
• ANTHIAS-2A — DisallowedHost: Invalid HTTP_HOST header: '141.212.44.121/..' — internet background-scanner noise hitting an exposed device; the classic Django django.security.DisallowedHost Sentry-noise case. Ignore that logger (like celery.worker.consumer.consumer/celery.beat) or filter DisallowedHost in before_send.

Fix shape: downgrade the AuthSettingsError/config-warning logging from error→warning (mirrors the lib/github.py change in #3019), and add DisallowedHost to the Sentry ignore set. All low-severity / non-actionable as events.

🤖 Generated with Claude Code