[langfuse-bot]

Generated from langfuse/langfuse main at ccfda83.

Confidence Score: 4/5

The PR still needs the previously reported fix for responses from older blob storage servers.

Summary

Updates the generated Python client from the latest API definition.

• Topics callers can read rules and see which rules use each facet.
• Topics callers can page through current summaries for traces and facets.
• Topics callers can page through each trace’s current topic assignment.
• S3 integrations can use an IAM role instead of stored access keys.
• Observation pages explain when callers need to keep following a cursor.
• Null filters can leave out the empty-string placeholder.
• Model docs mark tokenizer fields as legacy while keeping them in the API.

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

[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]

Older integration responses fail

If a self-hosted server predates IAM role authentication and does not return authType, the newly required BlobStorageIntegrationResponse.auth_type makes listing integrations or reading an update's response raise ValidationError. These calls worked before this change, even for callers using only access keys. Give the field a backward-compatible default, such as ACCESS_KEYS, so upgrading the SDK does not require upgrading the server.

Prompt To Fix With AI

This is a comment left during a code review.
Path: langfuse/api/blob_storage_integrations/types/blob_storage_integration_response.py
Line: 28-30

Comment:
**Older integration responses fail**

If a self-hosted server predates IAM role authentication and does not return `authType`, the newly required `BlobStorageIntegrationResponse.auth_type` makes listing integrations or reading an update's response raise `ValidationError`. These calls worked before this change, even for callers using only access keys. Give the field a backward-compatible default, such as `ACCESS_KEYS`, so upgrading the SDK does not require upgrading the server.

---

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

[claude]

🔴 SDK users on a Langfuse server older than this spec get a pydantic ValidationError when listing or upserting blob storage integrations. The new response field auth_type (alias authType) is required with no default. A server that predates IAM role auth omits authType, so the 2xx response no longer parses. Fix: make every response field this spec adds optional with a default, which covers the 2 sites listed. Do it in the upstream spec so regeneration keeps it, e.g. Optional[BlobStorageIntegrationAuthType] = None. Same pattern at 2 sites (blob_storage_integration_response.py:28, unstable/topics/types/topic_facet.py:22).

Why this was flagged

This triggers when the SDK runs against a self-hosted Langfuse deployment that has not yet picked up ccfda83, so its JSON has no authType. On the base branch BlobStorageIntegrationResponse has no such field, and those responses parse. After the change, blob_storage_integration_response.py:28-30 declares auth_type as Annotated[BlobStorageIntegrationAuthType, FieldMetadata(alias="authType")] with no default. Nothing tolerates the missing key: parse_obj_as in raw_client.py:271-273 (upsert) and in the list path raises a pydantic validation error, so a successful server response turns into an exception. extra="allow" only lets unknown keys through and does nothing for missing ones. The same thing happens with TopicFacet.rule_ids (alias ruleIds, pydantic.Field() with no default) at unstable/topics/types/topic_facet.py:22-24, so facet list calls fail against servers that do not send ruleIds. Every other field this regen adds (role_arn, external_id, rule_id, comment) is Optional with a default None. That shows these two required fields are the outliers.

Verification: Trigger: the SDK talks to a Langfuse server whose blob-storage integration responses predate IAM role auth and so carry no authType key. blob_storage_integration_response.py:28-30 adds auth_type with no default. The base version of the model has no auth_type field, so the same payload parses fine there. The try in raw_client.py only catches JSONDecodeError (line 128).

[claude]

🔴 SDK users whose server still requires the value: "" placeholder will get request validation errors when creating null filters, where the base client sent "value": "". The default moved from "" to None, and UniversalBaseModel.dict() drops unset None fields. So value is now left out of the request body. Fix: keep the default as "" (typing.Optional[typing.Literal[""]] = "") in both models so the placeholder is still sent, while still accepting omitted or null values on reads. Same pattern at 2 sites (null_evaluation_rule_filter.py:17, evaluation_rule_filter.py:650). [also at: langfuse/api/evaluation_commons/types/evaluation_rule_filter.py:650 - Evaluation rules with a null filter, created or updated against an older server, may now be rejected, because the SDK stops sending value: "".]

Why this was flagged

The condition is a self-hosted Langfuse server older than the upstream spec change. The removed docstring at null_evaluation_rule_filter.py:19 called value a "Required empty-string placeholder used by the runtime filter contract". On the base branch the default was "", which is non-None, so UniversalBaseModel.dict() (langfuse/api/core/pydantic_utilities.py:125-150) kept it in the exclude_none dump, and the body carried "value": "". Now value defaults to None at null_evaluation_rule_filter.py:17 and at EvaluationRuleFilter_Null in evaluation_rule_filter.py:650. Both the exclude_unset and the exclude_none dumps drop it, so the key is missing. A server that enforces the old contract rejects a null filter that the base SDK built correctly with the same caller code. Only new servers accept the omitted value, as the updated docs say ("omit, or """).

Verification: Trigger: the SDK sends a null filter to a self-hosted Langfuse server where value must be "". In null_evaluation_rule_filter.py:17 the default changes from "" to None. UniversalBaseModel.dict() in core/pydantic_utilities.py:125-150 merges an exclude_unset dump with an exclude_none dump. On the base the body carried "value": "". Now both dumps drop it and value is no longer sent.

[claude]

Code review found no new issues

No new issues were found in this update; 2 findings from earlier reviews are still open above.

Still open from earlier reviews (2):

• 🔴 langfuse/api/blob_storage_integrations/types/blob_storage_integration_response.py:30 — SDK users on a Langfuse server older than this spec get a pydantic ValidationError when listing or upserting blob stora…
• 🔴 langfuse/api/evaluation_commons/types/null_evaluation_rule_filter.py:17 — SDK users whose server still requires the value: "" placeholder will get request validation errors when creating null f…

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.