Langfuse ha pubblicato v4.25.0 il 31 agosto alle 10:42:43 UTC. Introduce un tetto di conservazione su quanto indietro può spingersi una query: 30 giorni per il livello Cloud Hobby e 90 giorni per Core. Il limite viene applicato a circa una dozzina di endpoint REST e sei strumenti MCP. La pull request è classificata come bug fix, non-breaking.

Perché questa classificazione è palesemente sbagliata

Un'API che ieri restituiva 180 giorni di trace e oggi ne restituisce 30 ha cambiato il proprio contratto. Non c'è nulla di invalido nella richiesta; la risposta viene semplicemente troncata. Qualsiasi dashboard, report pianificato o job di valutazione che calcola un dato trimestre su trimestre continua a funzionare, continua a restituire 200 e inizia a produrre una risposta diversa. Una modifica che altera i risultati senza modificare i codici di stato è il tipo più costoso da classificare come non-breaking, perché nulla a valle può rilevarla.

Il segnale che è stato calcolato e poi scartato

L'implementazione sa quando ha troncato una query — calcola un flag che indica che l'intervallo è stato ristretto. Quel flag non viene esposto. Non diventa un header di risposta, non diventa un campo nel payload e non diventa un avviso. Il server ha quindi l'informazione esatta di cui un client ha bisogno per sapere che i dati sono incompleti, e la elimina prima di rispondere. Aggiungere un solo header avrebbe trasformato un troncamento silenzioso in uno rilevabile, praticamente a costo zero.

Cosa sbaglia il framing comune

I limiti di conservazione nei livelli gratuiti sono ordinari e difendibili; un servizio ospitato ha il diritto di delimitare ciò che archivia e ciò che serve. La notizia non è che Langfuse abbia introdotto un limite. È come il limite viene erogato: come un clamp silenzioso e non annunciato, etichettato come non-breaking, su endpoint i cui consumatori sono automatizzati. Letto come "il tier gratuito ha una retention di 30 giorni", è una nota di prezzo. Letto come "una dozzina di endpoint ha iniziato silenziosamente a restituire meno dati", è un fallimento di osservabilità in un prodotto di osservabilità.

Cosa verificare

Qualsiasi metrica basata su Langfuse che copra più di 30 giorni su Hobby o 90 su Core dovrebbe essere ricalcolata dopo l'aggiornamento. Non andrà in errore. Sarà solo più piccola, e la differenza sembrerà un calo del traffico invece che un calo della visibilità.