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

[langfuse-bot]

Greptile Summary

Updates the generated API client to support filtering observations by session ID.

• Adds session_id to synchronous and asynchronous observation client methods.
• Serializes the filter as the sessionId query parameter.
• Documents boolean evaluation-rule filters and the isRootObservation column.

Confidence Score: 5/5

The PR appears safe to merge, with the new optional filter consistently wired through the synchronous and asynchronous generated clients.

The added parameter remains keyword-only, is forwarded unchanged to the raw clients, and is serialized under the expected sessionId query key; the remaining changes affect documentation only.

_{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 Fern API client update, mechanical and low-risk.

Extended reasoning...

Overview

This PR regenerates API client code from the langfuse OpenAPI spec (commit a162859). It adds a new session_id optional query parameter to observations.get_many (sync and async, client.py and raw_client.py), threaded through in the same pattern as existing parameters (docstring, signature, params dict). The third file, evaluation_rule_filter.py, only adds docstring text describing a new boolean/isRootObservation filter option for the unstable evaluation-rule filter API — no functional/type changes to the pydantic models themselves.

Security risks

None. This is read-only filter/query parameter plumbing for a GET endpoint; no auth, crypto, or permission logic is touched. The new session_id parameter is passed through as an opaque string to an httpx query param dict, consistent with existing string filters.

Level of scrutiny

Low. This is auto-generated Fern client code mirroring an upstream spec change, mechanically consistent with the existing codebase patterns (each new param mirrors the userId param wiring exactly). No hand-written business logic, no new abstractions, and the diff is straightforward parameter addition plus documentation strings.

Other factors

No prior reviews exist on this PR. The bug-hunting system found no issues, and my own read of the diff found the parameter threading correct and consistent between the sync/async and client/raw_client variants. This is a typical low-risk, auto-generated API-spec sync PR.