feat(api): update API spec from langfuse/langfuse 4e0ce09

[langfuse-bot]

Greptile Summary

Updates the generated unstable evaluation-rules API to represent read and update responses with a dedicated v2-readable model.

• Adds and publicly exports ReadableV2EvaluationRule.
• Uses permissive read-filter types so historical stored filters remain decodable.
• Updates synchronous and asynchronous update-response parsing and return annotations.
• Retains EvaluationRule for create responses while changing the readable union used by get and list responses.

Confidence Score: 5/5

The PR appears safe to merge with no actionable correctness or compatibility defect identified.

The synchronous and asynchronous clients, raw parsers, readable union, and public lazy exports are aligned, while the new read model broadens filter compatibility rather than rejecting shapes previously accepted.

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

Context used:

• Knowledge Base — Generated API service domains
• Knowledge Base — API compatibility and transport

[github-actions]

@claude review

[claude]

Looks good — straightforward auto-generated Fern SDK regeneration.

Reviewed: the new ReadableV2EvaluationRule type definition and its filter field import path (resolves to the existing langfuse/api/evaluation_commons/types/evaluation_rule_read_filter.py); the return-type swap from EvaluationRule to ReadableV2EvaluationRule across the sync/async client and raw_client update_evaluation_rule methods, including the parse_obj_as/typing.cast calls; and the export wiring in the three __init__.py files, which mirrors the existing ReadableEvaluationRule pattern exactly.

Extended reasoning...

Overview

This PR is an auto-generated Fern SDK update touching only langfuse/api/unstable/evaluation_rules/*. It adds a new ReadableV2EvaluationRule type (dedicated read-side model with a broader filter: List[EvaluationRuleReadFilter] field), rewires ReadableEvaluationRule to be Union[ReadableV2EvaluationRule, LegacyEvaluationRule] instead of Union[EvaluationRule, LegacyEvaluationRule], updates the update_evaluation_rule return type annotations and parsing calls across EvaluationRulesClient, AsyncEvaluationRulesClient, RawEvaluationRulesClient, and AsyncRawEvaluationRulesClient, and removes a stale/duplicated docstring example from EvaluationRule (replaced by an equivalent, corrected example on the new type).

Security risks

None. There is no auth, crypto, or permission logic here — purely typed data-model plumbing and export wiring for a generated client SDK. The filter field is a read-only response type; no new user input or serialization risk is introduced beyond what already exists in the existing filter/model machinery.

Level of scrutiny

Low. This is boilerplate-generated code following the exact structural pattern of the pre-existing ReadableEvaluationRule/EvaluationRule types and their export tables. I verified the new file's relative import path for EvaluationRuleReadFilter correctly resolves to the existing langfuse/api/evaluation_commons/types/evaluation_rule_read_filter.py module (four dots from langfuse.api.unstable.evaluation_rules.types lands on langfuse.api), and cross-checked all three __init__.py diffs — each new entry is added in the same three places (TYPE_CHECKING import, _dynamic_imports dict, __all__ list) consistent with how ReadableEvaluationRule itself is registered.

Other factors

The bug hunter reported no findings, and my own read of the diff surfaced nothing beyond mechanical, self-consistent changes. This is generated code (Fern) rather than hand-written logic, further lowering the risk of subtle bugs slipping in — errors here would typically be caught by the SDK's generation/build pipeline rather than requiring line-by-line human review.