@Michael 🇺🇦
Da der Fehler regelmäßig auftritt, habe ich die KI befragt. Das kam dabei heraus:
In der Friendica-Instanz trat beim Worker ein Foreign-Key-Fehler (MariaDB 1452) in der Tabelle inbox-status auf. Der Fehler entstand beim Aktualisieren des Inbox-Status im ActivityPub-/HTTP-Signature-Delivery-Pfad (HTTPSignature::setInboxStatus()).Ursache war ein historischer, inkonsistenter Datensatz aus dem Jahr 2022.
Beim späteren Aktualisierungsversuch wurde für diesen Datensatz uri-id = 0 gesetzt. Da inbox-status.uri-id per Foreign Key auf item-uri.id verweist und dort kein Datensatz mit id = 0 existiert, schlug das UPDATE mit Fehler 1452 fehl.
Die Untersuchung ergab:
- Es existierte genau ein Datensatz mit url = ''.
- Für gsid = 315 existierten keine aktuellen apcontact-Datensätze mit leerer Inbox.
- Es gab keine post-delivery-Einträge mit inbox-id = 0.
- Die übrigen 158.274 Datensätze mit uri-id IS NULL waren nicht die unmittelbare Ursache.
- Der problematische Datensatz wurde vor der Löschung separat gesichert.
- Die Sicherung wurde per SHA-256 erfolgreich verifiziert.
- Ein transaktionaler Dry Run bestätigte, dass genau dieser Datensatz entfernt werden konnte und per ROLLBACK wiederherstellbar war.
- Anschließend wurde genau eine Zeile gelöscht und per COMMIT dauerhaft entfernt.
Nach der Reparatur wurde der Worker wieder aktiviert und der Wartungsmodus deaktiviert. Die Friendica-Instanz läuft seitdem fehlerfrei; insbesondere ist der ursprüngliche Foreign-Key-Fehler bisher nicht erneut im Log aufgetreten.
Diese KI gab auch noch folgende Empfehlung:
Es sollte geprüft werden, warum HTTPSignature::setInboxStatus() bei einem historischen inbox-status-Eintrag mit leerer url bzw. fehlender uri-id letztlich versucht, uri-id = 0 zu speichern.Sinnvoll wäre insbesondere:
- leere bzw. ungültige Inbox-URLs vor der Statusaktualisierung abzufangen,
- niemals 0 als nicht vorhandene item-uri-ID zu verwenden — NULL ist im aktuellen Schema ausdrücklich zulässig,
- und einen Regressionstest für den konkreten Fall url='', uri-id=NULL einzubauen.Damit könnte Friendica solche historischen bzw. inkonsistenten Altbestände robust behandeln, anstatt bei einer späteren Federation-Aktivität einen Foreign-Key-Fehler im Worker zu erzeugen.
Der Fehler wurde auf jeden Fall erfolgreich gefixt. Ob die Empfehlung für die Friendica-Entwickler wichtig und relevant ist, kann ich nicht beurteilen.