feat: log through SLF4J and report errors to Sentry

[TheMeinerLP]

Gestapelt auf #207 (das wiederum auf #206). GitHub zieht die Base automatisch nach, sobald die Vorgänger gemergt sind.

Warum

Titan lief in Produktion faktisch blind:

1. Kein SLF4J-Binding. slf4j-api kam nur transitiv über Minestom, ein Provider war nie deklariert. Der Fat Jar antwortete auf jeden Log-Aufruf mit No SLF4J providers were found und verwarf ihn.
2. Minestoms Default-Exception-Handler ist Throwable::printStackTrace. Eine Exception in einem Listener landete roh auf stdout, an SLF4J vorbei.

Zusammen hieß das: ein abstürzender Listener hinterließ einen nackten Stacktrace und sonst nichts.

Logging

• logback-classic als runtimeOnly in :app und :setup, slf4j-api explizit deklariert
• eine logback.xml in :common — beide Fat Jars bündeln :common, also eine Konfiguration ohne Kopie
• TitanObservability.installExceptionHandler() ersetzt Minestoms printStackTrace-Default

Sentry

Optional, nach dem Muster von Sturnus: ohne TITAN_SENTRY_DSN wird Sentry.init nie aufgerufen und der Prozess verhält sich exakt wie heute. Ein Jar bedient Betreiber mit und ohne Sentry-Instanz.

Variable	Zweck
TITAN_SENTRY_DSN	Aktiviert Reporting. Fehlt sie, passiert nichts.
TITAN_SENTRY_ENVIRONMENT	production, beta, … — Default unknown

Die Release-Angabe kommt aus dem Implementation-Version-Manifest-Attribut des Fat Jars (neu in titan.java-conventions), ein Sentry-Issue zeigt also auf einen konkreten Deploy.

Reporting hat genau einen Eingang: den Logback-Appender ab ERROR. Kein zweiter, paralleler Pfad, der doppelt melden oder auseinanderlaufen könnte.

Spieler-Zuordnung

Wie besprochen mit UUID und Name.

EventNodeImpl fängt ab, was ein Listener wirft, und reicht es einen Frame höher an den ExceptionManager — auf demselben Thread. TitanObservability.guard() sitzt in diesem Frame, merkt sich den Spieler des fehlgeschlagenen Events und wirft weiter; der Handler legt ihn als player.uuid / player.name in den MDC, von wo der Sentry-Appender ihn übernimmt.

Kein Kostenpunkt auf dem gesunden Pfad. Aufgezeichnet wird ausschließlich im catch-Block. Ein Listener, der normal zurückkehrt, zahlt ein betretenes try und sonst nichts — relevant, weil zu den 18 gewrappten Listenern PlayerMoveEvent und PlayerPacketEvent gehören.

sendDefaultPii bleibt false: die PII-Defaults des SDK sind Request-Header und IP-Adressen, die über einen Minestom-Absturz nichts aussagen. Die Spieleridentität, die etwas aussagt, wird bewusst gesetzt.

Verifikation am echten Fat Jar

Ohne DSN:

INFO  [main] n.o.t.c.o.TitanObservability - Sentry reporting disabled - TITAN_SENTRY_DSN is not set
INFO  [main] luckperms - Loading configuration...
INFO  [main] luckperms - Successfully enabled. (took 388ms)
ERROR [main] n.o.t.c.o.TitanObservability - Unhandled exception
java.nio.file.NoSuchFileException: worlds

Mit DSN:

INFO  [main] n.o.t.c.o.TitanObservability - Sentry reporting enabled - release 1.14.0, environment smoketest

Vor dieser Änderung gab derselbe Lauf SLF4J(W): No SLF4J providers were found aus und danach einen nackten Stacktrace. Die Release-Angabe 1.14.0 belegt, dass das Manifest-Attribut greift.

Tests: 63 gesamt, 0 Fehler — davon 7 neue in :common:

• gewrappter Listener wird normal durchgereicht, ohne Kontext zu hinterlassen
• Fehlerfall wirft das Original unverändert weiter (assertSame)
• Fehler auf einem Player-Event zeichnet UUID + Name auf
• Kontext wird genau einmal konsumiert — sonst würde der nächste Fehler diesem Spieler angelastet
• Fehler auf einem Event ohne Spieler zeichnet nichts auf
• ohne DSN bleibt Sentry.isEnabled() false
• Release fällt außerhalb eines Jars auf dev zurück statt auf null

Ein Detail, das Erklärung braucht

Der Appender wird mit leerem DSN deklariert:

<options>
    <dsn>${TITAN_SENTRY_DSN:-}</dsn>
</options>

Er wird konstruiert, sobald der erste Logger entsteht — zwangsläufig bevor bootstrap() Sentry.init aufrufen kann. Ein Appender, der zu diesem Zeitpunkt keinen DSN findet, loggt DSN is required auf WARN, und das lässt Logback bei jedem Start seinen kompletten Konfigurations-Status ausgeben (~25 Zeilen). Mit leerem DSN ist der Start sauber; bootstrap() entscheidet ein paar Anweisungen später über die globale SDK-Instanz, ob tatsächlich gesendet wird.

Anmerkung

Commit-Typ ist feat: — anders als #206/#207 erscheint das hier also im Changelog. Das ist beabsichtigt: Betreiber müssen wissen, ab welcher Version TITAN_SENTRY_DSN gesetzt werden kann.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QtbnMbAj6m2q3vrDYFizDr