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

[langfuse-bot]

Greptile Summary

Updates the generated REST API client from the latest upstream specification.

• Adds synchronous and asynchronous feedback submission clients, request/response types, and typed errors.
• Adds deprecation metadata to legacy API response models.
• Expands unstable evaluation-rule responses to represent current and legacy rules.
• Updates package exports and legacy observation response typing.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete functional or security defects identified in the generated client update.

The new feedback resource is consistently exported and wired across synchronous and asynchronous clients, the evaluation-rule union correctly distinguishes current and legacy payloads, and the added deprecation metadata remains optional and backward compatible.

_{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 — auto-generated API client update from the Fern spec, consistent with prior spec-sync PRs in this repo.

What was reviewed: the new feedback client/types, the new Deprecation field added across several response models, the ObservationsViewSingle/ObservationsViews split, and the evaluation-rules restructuring (EvaluationRuleBase, LegacyEvaluationRule, ReadableEvaluationRule union). Checked that the legacy observations client return type was updated consistently across client.py/raw_client.py for both sync and async variants, and that __init__.py export lists stay in sync with the new types. No hand-written logic changes — all Pydantic models keep extra="allow" so this is purely additive.

Extended reasoning...

Overview

This PR is an auto-generated sync of the Python API client from the langfuse/langfuse OpenAPI spec (commit a9f0808), produced by the Fern generator. It adds: a new feedback client/endpoint (POST /api/public/feedback), a Deprecation marker field (_deprecation) added to many paginated/response models, a split of ObservationsView into ObservationsView/ObservationsViewSingle for the legacy single-observation GET endpoint, and a restructuring of the unstable evaluation_rules types to support legacy trace/dataset rules alongside the existing observation/experiment rules (new EvaluationRuleBase, LegacyEvaluationRule, ReadableEvaluationRule union type).

Security risks

None identified. All new/changed models are Pydantic UniversalBaseModel subclasses with `extra="allow", frozen=True", consistent with the rest of the generated client. The new feedback endpoint is a straightforward POST wrapper with no injection surface in this SDK layer (request construction is via typed fields passed to httpx, not string interpolation).

Level of scrutiny

Low-to-medium. This is fully auto-generated boilerplate from an external spec, not hand-authored logic — the correctness of behavior is bounded by the Fern generator and the upstream spec definition, not by this diff's authorship. I focused scrutiny on internal consistency (return-type changes propagated through client/raw_client for both sync/async, export lists staying in sync in the various __init__.py dynamic-import maps) rather than business logic, since there is none introduced here.

Other factors

This follows the same pattern as prior merged PRs in the repo's history (e.g. #1770, #1758-adjacent spec syncs), which were auto-generated the same way and merged without incident. The bug-hunting system found no issues; the one candidate it investigated (a legacy rule type reusing `EvaluationRuleFilter\the docstring calls the filter 'legacy-specific') was correctly ruled out — it's just how the upstream spec defines the type, not a python-sdk-introduced defect.