Commit Graph
1 Commits
Author SHA1 Message Date
RichardandClaude Opus 5 4c556be57d Einstellungen: erst schreiben, dann uebernehmen
CI / Build & Tests (Linux) (push) Canceled after 0s
CI / Plattformneutralität & Hygiene (push) Canceled after 0s
Behebt #534.

Die vier schreibenden Endpunkte verschluckten die Ausnahme des Repositories und
meldeten anschliessend unbedingt Erfolg. Das Verschlucken war unschoen; die
Reihenfolge war gefaehrlich: copyState wurde auch dann geaendert, wenn die
Datenbank abgelehnt hatte. Das Modul handelte danach mit Risikolimits, die
nirgends standen, und nach dem naechsten Neustart konnte niemand mehr
rekonstruieren, womit es gehandelt hatte.

Neu geht der Schreibvorgang zuerst, und der Hauptspeicher wird nur nachgezogen,
wenn er gelang. Sonst 500 mit Klartext und unveraenderter Zustand. Fehlt die
Ablage ganz, ist die Aenderung ebenso rein fluechtig — auch das wird abgelehnt,
mit 503.

Betroffen: CopyTrading-Kontoeinstellungen, ResolutionFarming-Kontoeinstellungen,
Master-Trader anlegen/aendern, Master-Trader loeschen.

Dass alle vier denselben Helfer (PersistenceGuard) benutzen, ist der eigentliche
Punkt: Aus je eigenem try/catch je Endpunkt ist die Ungleichheit ueberhaupt erst
entstanden.

Bewusst anders behandelt bleibt das Archivieren eines Supervisor-Berichts: Die
Antwort des Agenten steht dort bereits und hat Geld gekostet: sie wegen eines
fehlgeschlagenen Archiveintrags zu verwerfen, waere schlimmer als der fehlende
Eintrag, und an diesem Schreibvorgang haengt kein Verhalten des Systems.
Stillschweigend verschwindet er aber nicht mehr, sondern wird protokolliert.

In der Oberflaeche zeigten die Schreibwege bisher nur "HTTP 500" an und
verschenkten damit genau die Begruendung, die der Server jetzt mitliefert.
errorText() liest sie aus der Antwort.

Entscheidung von Richard: ablehnen statt fluechtig uebernehmen. Damit sind
waehrend eines Datenbankausfalls keine Aenderungen an den Einstellungen mehr
moeglich; das Handeln selbst laeuft weiter.

Geprueft auf der Linux-Test-VM mit angehaltener MariaDB: alle drei Schreibwege
antworten mit 500 und nennen den Grund, das Limit bleibt bei 11,25 statt auf
99,99 zu springen, der Phantom-Trader entsteht weder im Hauptspeicher noch in
der Datenbank, jeder Fehlschlag steht im Protokoll. Nach dem Wiederanlauf
speichert es wieder. 556 von 556 Tests bestanden (5 neue).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 15:51:16 +02:00