Falukant Smoke-Test: Tod -> Erbwechsel -> UI-Status

Dieser Smoke-Test validiert den kritischen Ablauf:

Spieler-Charakter stirbt
Erbe wird gesetzt
alte charakterbezogene Daten sind bereinigt
UI bekommt verlässlich den Status-Refresh

Ziel

Verhindern, dass nach Tod/Erbe ein Mischzustand entsteht (z. B. Erben-Bild, aber alte Statusdaten des verstorbenen Charakters).

Voraussetzungen

Daemon läuft mit aktuellen Änderungen.
Migration 020_falukant_character_relation_cleanup.sql ist eingespielt.
Zugriff auf DB (psql).
Zugriff auf WebSocket-Eventstream oder Daemon-Log.
Ein Test-User mit:
- aktivem Spieler-Charakter (user_id gesetzt),
- mindestens einem potenziellen Erben in child_relation.

Testfall A: Tod über `UserCharacterWorker` (health <= 0)

Testkandidaten wählen:

SELECT c.id AS character_id, c.user_id
FROM falukant_data.character c
WHERE c.user_id IS NOT NULL
ORDER BY c.updated_at DESC
LIMIT 20;

Einen Charakter künstlich auf health = 0 setzen:

UPDATE falukant_data.character
SET health = 0, updated_at = NOW()
WHERE id = <CHARACTER_ID>;

Worker laufen lassen (Death-Check oder nächster Verarbeitungstakt).
WebSocket/Log prüfen, erwartet:
- CharacterDeath mit altem character_id
- falukantUpdateStatus mit user_id des betroffenen Spielers
DB prüfen, erwartet:

-- alter Charakter weg
SELECT 1
FROM falukant_data.character
WHERE id = <CHARACTER_ID>;

-- Spieler zeigt auf Erben
SELECT c.id, c.user_id
FROM falukant_data.character c
WHERE c.user_id = <USER_ID>;

-- Todes-Cleanup (sollte leer sein)
SELECT COUNT(*) FROM falukant_data.relationship
WHERE character1_id = <CHARACTER_ID> OR character2_id = <CHARACTER_ID>;
SELECT COUNT(*) FROM falukant_data.child_relation
WHERE child_character_id = <CHARACTER_ID>
   OR father_character_id = <CHARACTER_ID>
   OR mother_character_id = <CHARACTER_ID>;
-- Es dürfen auch keine Zustände gelöschter Beziehungen zurückbleiben.
SELECT COUNT(*) FROM falukant_data.relationship_state rs
WHERE NOT EXISTS (SELECT 1 FROM falukant_data.relationship r WHERE r.id = rs.relationship_id);
SELECT COUNT(*) FROM falukant_data.knowledge WHERE character_id = <CHARACTER_ID>;
SELECT COUNT(*) FROM falukant_data.debtors_prism WHERE character_id = <CHARACTER_ID>;
SELECT COUNT(*) FROM falukant_data.political_office WHERE character_id = <CHARACTER_ID>;
SELECT COUNT(*) FROM falukant_data.election_candidate WHERE character_id = <CHARACTER_ID>;

-- politische Ämter historisiert (falls vorher vorhanden)
SELECT *
FROM falukant_log.political_office_history
WHERE character_id = <CHARACTER_ID>
ORDER BY end_date DESC
LIMIT 5;

Passkriterium:

alter Charakter gelöscht,
Nachfolger gesetzt,
Cleanup-Counts = 0,
falukantUpdateStatus gesendet.

Testfall B: Tod über `EventsWorker`

Der gleiche Prüfsatz wie in Testfall A, aber mit Tod aus Event-Pfad.

Hinweis:

Falls kein reproduzierbares Zufallsereignis vorliegt, kann derselbe technische Endzustand pragmatisch über A validiert werden.
Zusätzlicher Fokus hier: auch im Event-Pfad müssen Cleanup + Status-Refresh identisch sein.

UI-Schnellcheck

Nach Eintreffen von falukantUpdateStatus:

Avatar/Bild entspricht dem Erben.
Statusdaten (Familie/Politik/bezogene Anzeigen) zeigen keine Relikte des Verstorbenen.
Kein inkonsistenter Mischzustand nach manuellem Reload.

Regression-Checkliste

CharacterDeath kommt genau für den verstorbenen Charakter.
falukantUpdateStatus kommt nach Erbwechsel für den betroffenen User.
knowledge/debtors_prism/political_office/election_candidate sind bereinigt.
relationship/relationship_state/child_relation sind bereinigt (beide Partner, alle drei Kind-/Elternrollen).
Kindstod benachrichtigt auch einen einzelnen bekannten Elternteil (NULL beim anderen Elternteil).
Ein Benachrichtigungsfehler unterbricht den NPC-Todes-Cleanup nicht.
political_office_history enthält entfernte Ämter (falls vorhanden).
UI bleibt konsistent (Bild + Status gehören zum selben Charakter).

4.0 KiB Executable File Raw Blame History