feat(api): update API spec from langfuse/langfuse 62b7c3e

[langfuse-bot]

Confidence Score: 3/5

The PR does not appear safe to merge until dataset response compatibility and the removed public imports are addressed.

Summary

The API-spec refresh adds filtering and lookup hints, revises legacy-ingestion guidance, and consolidates cursor metadata.

• The narrowed dataset response type can reject boolean JSON Schemas.
• Removing public SDK-log types breaks existing imports.
• The OpenTelemetry example omits the header its new real-time guidance requires.

_{Reviews (1) · Last reviewed commit: "feat(api): update API spec from langfuse..."}

[github-actions]

@claude review

[claude]

Claude Code Review

No review was started: this request came from a bot account. Manual reviews can only be requested by someone with write access to this repository. Ask a maintainer to comment @claude review, or have your automation post the comment from a user account with write access.

_{Tip: disable this comment in your organization's Code Review settings.}

[greptile-apps]

Boolean schemas break dataset responses

A boolean is a valid JSON Schema, and the high-level create_dataset method accepts and forwards one. If the API returns that schema in the dataset response, the new Dict type rejects it during response validation. Dataset creation or retrieval then raises instead of returning the dataset. The same issue applies to expected_output_schema.

Prompt To Fix With AI

This is a comment left during a code review.
Path: langfuse/api/commons/types/dataset.py
Line: 25-28

Comment:
**Boolean schemas break dataset responses**

A boolean is a valid JSON Schema, and the high-level `create_dataset` method accepts and forwards one. If the API returns that schema in the dataset response, the new `Dict` type rejects it during response validation. Dataset creation or retrieval then raises instead of returning the dataset. The same issue applies to `expected_output_schema`.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Public SDK log imports break

Applications importing the previously exported SdkLogEvent, SdkLogBody, or IngestionEvent_SdkLog now fail at import time. The ingestion endpoint remains available before its stated November 2026 cutoff, so removing these public types breaks existing client code ahead of that migration.

Prompt To Fix With AI

This is a comment left during a code review.
Path: langfuse/api/ingestion/types/__init__.py
Line: 64

Comment:
**Public SDK log imports break**

Applications importing the previously exported `SdkLogEvent`, `SdkLogBody`, or `IngestionEvent_SdkLog` now fail at import time. The ingestion endpoint remains available before its stated November 2026 cutoff, so removing these public types breaks existing client code ahead of that migration.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline finding on evaluation_rule_filter.py, I also checked the narrowed inputSchema/expectedOutputSchema typing in dataset.py (now Optional[Dict[str, typing.Any]] instead of Optional[Any]) — ruled out as a practical break since these fields are always JSON-object schemas in practice, not a general bug.

Extended reasoning...

This PR is an auto-regenerated Fern API client update (prompts list filter param, removal of SdkLog ingestion types, pagination meta reshaping, minor field additions) with one confirmed inline finding already posted about EvaluationRuleFilter_StringObject's operator typing rejecting documented "is set"/"is not set" values. I additionally reviewed the dataset.py schema field type narrowing for a similar validation-break risk and ruled it out as low-risk given the field's expected shape.

[claude]

🟡 (optional) Callers who build EvaluationRuleFilter_StringObject with operator="is set"/"is not set", now documented as valid at line 416, get a pydantic ValidationError instead of the request the docs promise. EvaluationRuleFilter_StringObject.operator (line 456) is typed EvaluationRuleStringFilterOperator, an enum with only "=", "contains", "does not contain", "starts with", "ends with" (langfuse/api/evaluation_commons/types/evaluation_rule_string_filter_operator.py, unchanged by this PR). Fix: add "is set"/"is not set" to that enum (or introduce a dedicated stringObject operator enum) so it matches every one of the 9 updated stringObject docstrings in this file, keeping the existing 5 operators valid for plain string filters.

Why this was flagged

A caller uses create_evaluation_rule/update_evaluation_rule (langfuse/api/evaluation_rules/raw_client.py) and constructs EvaluationRuleFilter_StringObject(type="stringObject", column="metadata", key="...", operator="is set", value="") as a real pydantic object, following the operator list this diff just added at evaluation_rule_filter.py:416 (and repeated at lines 37,100,163,226,289,353,480,544,607). Pydantic validates enum membership at construction time against EvaluationRuleStringFilterOperator, which still only defines EQUALS/CONTAINS/DOES_NOT_CONTAIN/STARTS_WITH/ENDS_WITH, so construction raises before any request is sent - on base this operator wasn't documented so no one hit it, now it's advertised but unusable via the typed constructor. Passing a raw dict instead bypasses this (convert_and_respect_annotation_metadata does no enum validation), so only the documented, typed usage path fails.

Verification: nit. Real doc/type mismatch, but the code enforcement is pre-existing and unchanged; the diff only adds an over-promising docstring. The diff changed the shared docstring (evaluation_rule_filter.py:416, and identically at lines 37/100/163/226/289/353/480/544/607) from stringObject: same operators as string to `stringObject: "=", contains, does not contain, starts with, ends with, is set, is…