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

[langfuse-bot]

Greptile Summary

This generated API update introduces a readable V2 evaluation-rule model and uses it for update, get, and list response contracts while retaining the stricter write-oriented model.

• Changes evaluation-rule update responses to ReadableV2EvaluationRule.
• Allows read responses to represent historical filter shapes through EvaluationRuleReadFilter.
• Exports the new generated type and moves its API example from the write-oriented model.

Confidence Score: 5/5

The PR appears safe to merge, with the generated response types and public exports remaining internally consistent.

The update, get, and list response models now consistently distinguish readable historical filter data from the stricter write contract, and all newly referenced types resolve through the existing export hierarchy.

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

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
langfuse-js	Ready	Preview	Aug 31, 2026 6:56am

[github-actions]

@claude review

[claude]

Looks good — a mechanical, auto-generated Fern SDK update to the unstable evaluationRules types/client.

What was reviewed: the update() client method's return type change from EvaluationRule to the new ReadableV2EvaluationRule; the new ReadableV2EvaluationRule type shape and its filter/mapping fields against the pre-existing analogous stable type in evaluationRules/types/EvaluationRule.ts (same EvaluationRuleReadFilter type is already used there, confirming it's a valid, existing type); and the ReadableEvaluationRule union and index.ts export update. No hand-written logic or tests were touched.

Extended reasoning...

Overview

This PR is an auto-generated Fern SDK update (all files carry the "auto-generated by Fern" header) affecting the unstable.evaluationRules resource in packages/core. It adds a new ReadableV2EvaluationRule interface (mirroring the old EvaluationRule but typing filter as LangfuseAPI.EvaluationRuleReadFilter[] instead of the stricter unstable filter type), re-exports it, and switches ReadableEvaluationRule and the update() client method's return type to use it. The old EvaluationRule interface remains, minus its large @ example doc comment, and is still exported from index.ts.

Security risks

None. This is purely a type/client-surface change with no new I/O, auth, or data-handling logic — the HTTP call in Client.ts is unchanged except for a type-only cast on the response body.

Level of scrutiny

Low. This is mechanical generated code mirroring an existing pattern already present elsewhere in the codebase (the stable evaluationRules/types/EvaluationRule.ts already uses LangfuseAPI.EvaluationRuleReadFilter[] for its filter field), and I confirmed that type exists and is defined in evaluationCommons/types/EvaluationRuleReadFilter.ts. No hand-written logic, tests, or runtime behavior are affected — the change only widens/relaxes the read-side filter type for an "unstable" API surface, consistent with the stated purpose (accepting historical filter shapes on read).

Other factors

I could not run tsc in this sandboxed environment (Bash permission denied for that command), so I relied on manual verification that referenced types (EvaluationRuleReadFilter, EvaluationRuleEvaluatorAssignment, EvaluationRuleTarget, PromptVariableMappingRead) already exist elsewhere in the generated tree and are used identically in the sibling stable module. The PR has a linked Vercel comment (likely a preview deployment check) with no CHANGES_REQUESTED or unresolved objections visible in the timeline. This is a small, self-contained, generated-code change with no ambiguity, so I'm approving.