Langfuse 4.2 löst kein Datenvolumen-Problem pauschal, aber es entschärft einen besonders unangenehmen Ingestion-Fall: Übergroße Eingabe-, Ausgabe- und einzelne Metadatenfelder können im neuen direkten Event-Pfad in Media ausgelagert werden. Für Teams mit agentischen Traces ist das eine brauchbare Schutzschicht – allerdings nur nach bewusstem Opt-in und nicht für jeden Schreibmodus.
Was sich in 4.2 ändert
Das am 31. Juli veröffentlichte Release ergänzt zwei operative Bausteine. Erstens bekommt MCP-Telemetrie kanonische, aggregierbare Outcomes. Zweitens kann der Worker übergroße Felder beim direkten Schreiben nach events_full in den Media-Store verschieben und im Event durch einen Media-Verweis ersetzen.
Der Default ist bewusst konservativ: Die Funktion ist deaktiviert. Aktiv wird sie auf dem Worker mit:
LANGFUSE_OBSERVATION_FIELD_OVERFLOW_ENABLED=true
LANGFUSE_OBSERVATION_FIELD_SIZE_LIMIT_BYTES=20971522 MiB ist der Standard für die Größe pro Feld. Geprüft werden Observation-Input, -Output und jeder persistierte Metadatenwert in UTF-8-Bytes. Erst oberhalb des Limits entsteht ein Upload; kleinere Felder werden ohne Content-Buffer gemessen. Das ist relevanter als es klingt: Tool-Ergebnisse, große Retrieval-Anhänge oder Debug-Payloads können sonst den Hot Path für Observability unnötig belasten.
Die Einschränkung, die Betreiber nicht überlesen sollten
Version 1 gilt ausschließlich für direkte Event-Table-Ingestion über IngestionService.writeEventRecord(). Legacy-observations-Writes und staging-basierte Dual-Writes bleiben unverändert. Wer noch im Legacy-Modus arbeitet, erhält durch das Setzen der Variable also keinen Schutz. Und falls der Media-Upload scheitert, arbeitet der Pfad „fail open“: Langfuse protokolliert eine Warnung, persistiert aber den ursprünglichen großen Wert weiter.
Der neue Mechanismus ist kein Payload-Limit. Er ist eine gezielte Auslagerung am direkten Write-Boundary – und hängt damit an Datenpfad und Media-Storage-Gesundheit.
MCP-Fehler werden vergleichbar
Parallel führt 4.2 kanonische MCP-Tool-Outcomes für die Dashboard- und Metrik-Ebene ein. Damit lassen sich Request-Fehler und Server-Fehler als begrenzte Kategorien auswerten, statt Fehlersignale nur in individuellen Span-Details zu suchen. Außerdem überspringt der Worker Tokenisierung, wenn bereits Kostendetails mitgeliefert werden und die Berechnung das Token-Ergebnis nicht benötigt.
Praktischer nächster Schritt
- Den aktiven Write-Modus prüfen: Nur direkte Event-Ingestion liegt im Scope.
- Media-Storage und Worker-Zugriff testen; bei Ausfall greift kein harter Schutz.
- Ein realistisches großes Tool- oder Retrieval-Payload in Staging senden und die Media-Referenz im Trace prüfen.
- Das 2-MiB-Limit nicht blind senken: Es ist eine Grenze pro Feld, nicht pro Event.
Quellen
- Langfuse v4.2.0 Release – veröffentlicht am 31. Juli 2026, 07:46 UTC.
- Langfuse PR #15350: oversized direct-event fields to media – Implementierungsdetails, Konfiguration und Fehlerverhalten.
Leave a Reply