Fix "Empfänger"-Speicherfehler + Regeln bearbeiten (#10) #14

Merged

glow merged 1 commit from feature/10-rules-edit-and-migration-fix into main 2026-07-08 22:06:27 +00:00

Conversation 1 Commits 1 Files changed 5 +340 -28

glow commented 2026-07-08 22:04:30 +00:00 (Migrated from gitlab.fluffyplace.de)

Copy link

Closes #10.

Bug: Regel mit Feld "Empfänger" ließ sich nicht speichern

Ursache 1: Datenbanken von vor dem Merge von #4 haben noch den alten CHECK (field IN ('buchungstext', 'vorgang'))-Constraint auf rules.field — SQLite kann Constraints nicht per ALTER TABLE ändern, und die damalige Migration hat nur die Spalte merchant_name ergänzt, nicht diesen Constraint auf bestehenden DBs repariert. Der Fehler war zudem komplett unbehandelt (rohe Stacktrace-HTML-Seite).

Fix: Migration macht jetzt einen Table-Rebuild (SQLite-Standardverfahren für Constraint-Änderungen), automatisch und idempotent beim Start.

Ursache 2 (beim Testen des Fixes gefunden): Der Table-Rebuild von rules per CREATE+DROP (statt RENAME) lässt rule_tags' Fremdschlüssel auf den zwischenzeitlich umbenannten/gelöschten Tabellennamen zeigen — SQLite schreibt Fremdschlüssel-Referenzen automatisch nur bei ALTER TABLE ... RENAME um, nicht bei CREATE+DROP. Jede spätere Schreiboperation auf rule_tags (z.B. beim Speichern eines Tags an einer Regel) crashte dadurch mit "no such table". Reproduziert und behoben, indem rule_tags beim Rebuild mit korrekter Referenz neu aufgebaut wird.

Zusätzlich: POST/PATCH auf Regeln laufen jetzt in einer einzigen Transaktion (Regel + Tags), damit bei einem Fehler nichts halb angewendet bleibt. Und ein globaler Express-Error-Handler sorgt dafür, dass jede unbehandelte Exception als sauberes JSON statt als Stacktrace-Seite rausgeht.

Feature: Regeln bearbeiten

PATCH /api/rules/:id plus Bearbeiten-Button (✎) pro Regel, der das Formular mit den aktuellen Werten befüllt und in einen Update-Modus wechselt (inkl. "Abbrechen").

Tests

db.test.ts reproduziert den ursprünglichen Crash gegen eine simulierte Vor-#4-Datenbank und verifiziert den Fix — inklusive einer gezielten Assertion, dass eine neue rule_tags-Zeile nach der Migration geschrieben werden kann (genau der Fall, der den zweiten Bug aufgedeckt hätte, wäre er nicht dabei gewesen). Zusätzlich end-to-end gegen eine echte alte Datenbank und eine frische Datenbank verifiziert (Anlegen, Bearbeiten, Löschen, inkl. Tag-Zuordnung, 404/400-Fälle). Bestehende Suite weiterhin grün (26 Tests).

Closes #10. ## Bug: Regel mit Feld "Empfänger" ließ sich nicht speichern **Ursache 1**: Datenbanken von vor dem Merge von #4 haben noch den alten `CHECK (field IN ('buchungstext', 'vorgang'))`-Constraint auf `rules.field` — SQLite kann Constraints nicht per `ALTER TABLE` ändern, und die damalige Migration hat nur die Spalte `merchant_name` ergänzt, nicht diesen Constraint auf bestehenden DBs repariert. Der Fehler war zudem komplett unbehandelt (rohe Stacktrace-HTML-Seite). **Fix**: Migration macht jetzt einen Table-Rebuild (SQLite-Standardverfahren für Constraint-Änderungen), automatisch und idempotent beim Start. **Ursache 2 (beim Testen des Fixes gefunden)**: Der Table-Rebuild von `rules` per CREATE+DROP (statt RENAME) lässt `rule_tags`' Fremdschlüssel auf den zwischenzeitlich umbenannten/gelöschten Tabellennamen zeigen — SQLite schreibt Fremdschlüssel-Referenzen automatisch nur bei `ALTER TABLE ... RENAME` um, nicht bei CREATE+DROP. Jede spätere Schreiboperation auf `rule_tags` (z.B. beim Speichern eines Tags an einer Regel) crashte dadurch mit "no such table". Reproduziert und behoben, indem `rule_tags` beim Rebuild mit korrekter Referenz neu aufgebaut wird. **Zusätzlich**: `POST`/`PATCH` auf Regeln laufen jetzt in einer einzigen Transaktion (Regel + Tags), damit bei einem Fehler nichts halb angewendet bleibt. Und ein globaler Express-Error-Handler sorgt dafür, dass jede unbehandelte Exception als sauberes JSON statt als Stacktrace-Seite rausgeht. ## Feature: Regeln bearbeiten `PATCH /api/rules/:id` plus Bearbeiten-Button (✎) pro Regel, der das Formular mit den aktuellen Werten befüllt und in einen Update-Modus wechselt (inkl. "Abbrechen"). ## Tests `db.test.ts` reproduziert den ursprünglichen Crash gegen eine simulierte Vor-#4-Datenbank und verifiziert den Fix — inklusive einer gezielten Assertion, dass eine *neue* `rule_tags`-Zeile nach der Migration geschrieben werden kann (genau der Fall, der den zweiten Bug aufgedeckt hätte, wäre er nicht dabei gewesen). Zusätzlich end-to-end gegen eine echte alte Datenbank **und** eine frische Datenbank verifiziert (Anlegen, Bearbeiten, Löschen, inkl. Tag-Zuordnung, 404/400-Fälle). Bestehende Suite weiterhin grün (26 Tests).

glow (Migrated from gitlab.fluffyplace.de) merged commit 7e00d6e2e0 into main 2026-07-08 22:06:27 +00:00

glow commented 2026-07-08 22:06:28 +00:00 (Migrated from gitlab.fluffyplace.de)

Copy link

mentioned in commit 7e00d6e2e0

mentioned in commit 7e00d6e2e0e12f17a187bbcf72f9d69484811c16

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

diskussion

  

feature-idee

No labels

diskussion

feature-idee

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

budmin/finanzplaner!14

No description provided.