Langfuse 于 8 月 31 日 UTC 10:42:43 发布了 v4.25.0。此次更新为查询可追溯的时间范围引入了保留上限：Cloud Hobby 套餐为 30 天，Core 为 90 天。这一上限应用于大约 十几个 REST 端点和 6 个 MCP 工具。该 pull request 被归类为 bug 修复、非破坏性。
为什么这种归类表面上就站不住脚
昨天还返回 180 天 traces 的 API，今天却只返回 30 天，等于改变了其契约。请求本身并没有任何无效之处；只是响应被截断了。任何计算环比数据的仪表盘、定时报告或评估任务，都会继续运行，继续返回 200，并开始给出不同的答案。一个在不改变状态码的情况下改变结果的更新，是最昂贵的那类“非破坏性”变更，因为下游系统根本无法察觉。
被计算出来却被丢弃的信号
该实现确实知道自己何时截断了查询——它会计算一个标志，表明范围已被 clamp。但这个标志没有对外暴露：既不会变成响应头，也不会成为载荷中的字段，更不会变成警告。因此，服务器掌握着客户端判断数据是否不完整所需的全部信息，却在回复前将其丢弃。只要加一个头部，就能把一次静默截断变成可检测的截断，成本几乎为零。
常见叙述忽略了什么
免费套餐上的保留上限很常见，也完全说得通；托管服务有权限制其存储和提供的内容。问题不在于 Langfuse 引入了限制，而在于它如何呈现这项限制：以未提前告知的静默 clamp 方式实施，并被标注为非破坏性，而这些端点的消费者又是自动化系统。若将其理解为“免费层仅保留 30 天数据”，那只是价格脚注；若理解为“十几个端点悄然开始返回更少数据”，那就是一款可观测性产品中的可观测性失效。
需要检查什么
凡是基于 Langfuse、且跨度超过 Hobby 套餐 30 天或 Core 套餐 90 天的指标，都应在升级后重新推导。系统不会报错，只会变小，而这种变化看起来更像流量下降，而不是可见性下降。