feat(api): update API spec from langfuse/langfuse dffb1f4

[langfuse-bot]

Greptile Summary

Updates the generated API client to match the latest upstream specification.

• Adds typed deprecation metadata to deprecated endpoint responses.
• Introduces readable legacy evaluation-rule models and updates list/get responses to support them.
• Preserves observation response compatibility through a specialized subclass with deprecation metadata.

Confidence Score: 5/5

The PR appears safe to merge, with the generated response models and client parsing remaining internally consistent.

The new response metadata is optional, observation responses remain compatible through inheritance, and current versus legacy evaluation rules are distinguished by their non-overlapping target enums during union validation.

_{Reviews (1): Last reviewed commit: "feat(api): update API spec from langfuse..." | Re-trigger Greptile}

Context used:

• Knowledge Base — API Client (langfuse/api/)

[github-actions]

@claude review

[claude]

LGTM — this is an auto-generated API client update (Fern codegen) with no hand-written logic changes.

What was reviewed: the widened Deprecation field additions across response models, the new ObservationsViewSingle type used by the legacy single-observation endpoint, and the EvaluationRule split into EvaluationRuleBase/EvaluationRule/LegacyEvaluationRule with get now returning the ReadableEvaluationRule union. All changes are mechanical additions of optional fields or new generated types consistent with the existing codegen patterns; no runtime logic was hand-modified.

Extended reasoning...

Overview

This PR is an auto-generated update of the Langfuse Python API client (via Fern) reflecting changes in the upstream langfuse/langfuse API spec. It touches 32 files, all within langfuse/api/, adding: a new Deprecation commons type used as an optional _deprecation field across several paginated/detail response models; a new ObservationsViewSingle type for the legacy single-observation-get endpoint; and a restructuring of evaluation rule types (EvaluationRuleBase extracted as a shared base, new LegacyEvaluationRule/LegacyEvaluationRuleMapping/LegacyEvaluationRuleTarget/LegacyEvaluationObject/EvaluationRuleTimeScope types, and a ReadableEvaluationRule union now returned by the evaluation-rules get endpoint instead of the bare EvaluationRule).

Security risks

None identified. This is a typed data-model / client-stub update with no authentication, authorization, injection, or data-handling logic — all classes are Pydantic models with extra="allow", frozen=True config consistent with the rest of the generated client, and no new HTTP behavior beyond swapping response deserialization types.

Level of scrutiny

Low. This is fully auto-generated boilerplate (marked "This file was auto-generated by Fern from our API Definition") mirroring a spec change in the upstream API. The correct level of scrutiny is a sanity check that the generated code is internally consistent (imports, `all" lists, dynamic import maps) rather than a logic review, since there is no hand-authored business logic to evaluate.

Other factors

The one behavior change worth flagging for future consumers is that evaluation_rules.get()" now returns ReadableEvaluationRule = Union[EvaluationRule, LegacyEvaluationRule]" instead of a bare EvaluationRule, which is a typing-level change downstream callers may need to handle (e.g., checking target to discriminate). This is intentional per the docstring updates (legacy trace/dataset rules are now returned for migration purposes) and matches the upstream spec intent, not a bug. A bug-hunting pass already ran and found nothing, and a finder-raised concern about LegacyEvaluationRule.filter" reusing the modern EvaluationRuleFilter" type was independently ruled out. Given the mechanical nature and consistency with existing codegen conventions, I'm comfortable approving without human review.