www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/7ed1a6fb-ca23-4625-a5be-c218d86b6f7c/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

TYPO3\CMS\Extbase\Persistence\Generic\Storage\Exception\SqlErrorException: An exception occurred while executing a query: Incorrect DATE value: '2026…

Automatisch erstellt durch n8n

KI-Analyse:

Hier ist die Analyse des Fehlers:

1. Ursache identifizieren¶

Der Fehler mysqli_sql_exception: Incorrect DATE value deutet darauf hin, dass MySQLi versucht, einen Wert in ein Datumsfeld (Date Column) einzufügen, der jedoch kein gültiges Datum darstellt. Der konkrete fehlerhafte Wert lautet:
'2026-RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15) from dual)'

Dieser Wert ist syntaktisch für MySQL unbrauchbar. Er sieht aus wie eine verkettete Zeichenkette, die einen Jahreswert (2026) mit einem zufälligen Text (RECEIVE_MESSAGE...) und numerischen Anhängen mischt. Es handelt sich um einen klassischen Type-Mismatch-Fehler, bei dem ein Parameter (vermutlich aus einer URL oder einem Header) fälschlicherweise als Datum übergeben wurde, statt als String oder anderer Datentyp. Die Kombination mit DBMS_PIPE im Log könnte auf eine spezifische Middleware-Logik hindeuten, die Datenströme verarbeitet, aber den Typ nicht korrekt validierte.

2. Fix beschreiben (konkret)¶

Das Problem liegt in der Datenverarbeitung vor der Datenbankinteraktion. Der Fix muss zwei Ebenen umfassen:

• Validierung im Middleware-Stack: Der Wert RECEIVE_MESSAGE (und ähnliche dynamische Parameter) muss vor der Weiterleitung an die Datenbank streng gegen das ISO-8601-Datumsformat (YYYY-MM-DD) geprüft werden. Falls der Wert nicht diesem Muster entspricht, muss er verworfen oder ein Standardwert gesetzt werden.
• Typprüfung beim Einfügen: Bei der Konstruktion der SQL-Abfrage oder beim Binding von Parametern muss sichergestellt werden, dass der Wert explizit als DATETIME oder TIMESTAMP behandelt wird. Ein String wie oben sollte niemals direkt in einen WHERE-Klausel-Wert oder einen INSERT-Eintrag ohne vorherige Cast-Operation eingefügt werden.

Konkreter Code-Ansatz:
Im Middleware-Kontext (z. B. NormalizedParamsAttribute oder VerifyHostHeader) sollte eine Prüfung implementiert werden:

// Beispielhafte Logik zur Validierung
if ($param = $request->get('RECEIVE_MESSAGE')) {
    // Prüfe ob der Wert ein gültiges Datum ist
    if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $param)) {
        // Fehlerbehandlung: Parameter ignorieren oder Default setzen
        return false; 
    }
}

Alternativ kann die Datenbankabfrage so modifiziert werden, dass sie den Typ explizit erzwingt (z. B. durch Verwendung von CAST() oder CONVERT_DATETIME()), falls der Fehler durch eine falsche Reihenfolge der Operationen (String-Verbindung vor Datums-Bindungsfunktion) verursacht wurde.

3. Betroffene TYPO3 Extension nennen¶

Die betroffene Komponente ist TYPO3 CMS Core (spezifisch die Module, die den HTTP-Handling-Mechanismus nutzen, z. B. Typo3_CMS oder Typo3_Website). Da der Stack Trace ausschließlich im vendor/typo3/cms-core Bereich verbleibt, liegt der Fehler im Kern der CMS-Plattform selbst.

4. Confidence (0-100%)¶

92%