Comment on In den Friendica Logfiles (Loglevel Error) tauchen folgende Meldungen mehrfach a

heluecht@pirati.ca@pirati.ca ⁨2⁩ ⁨days⁩ ago

• tux@anonsys.net ⁨2⁩ ⁨days⁩ ago

  @heluecht
  Also eine falsche DB-Aktion bei Friendica weil "Daten gelöscht werden, die mit anderen Tabellen zusammenhängen, die wiederum nicht gelöscht werden sollen.". Sprich ein Bug und kein lokales Problem der Instanz selber?
  Oder habe ich das falsch verstanden?

  original

  • heluecht@pirati.ca@pirati.ca ⁨2⁩ ⁨days⁩ ago

    @tux Das lässt sich nicht mit Gewissheit sagen. Im Moment kann ich nicht sagen, wie man das sauber und sicher beheben kann.

    original

    • tux@anonsys.net ⁨1⁩ ⁨day⁩ ago

      @heluecht
      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.

      original