Skip to content

feat(api): update API spec from langfuse/langfuse 5b59af4 - #1895

Closed
langfuse-bot wants to merge 1 commit into
mainfrom
api-spec-bot-5b59af4-35779498517-1
Closed

langfuse-bot wants to merge 1 commit into
mainfrom
api-spec-bot-5b59af4-35779498517-1

Conversation

@langfuse-bot

@langfuse-bot langfuse-bot commented Sep 22, 2026 •

Copy link
Copy Markdown
Collaborator

RetriggerConfidence Score: 3/5

The PR is not safe to merge until the public SDK-log compatibility break and missing real-time ingestion header behavior are resolved.

Summary

This generated API update expands filtering and lookup hints, updates v3/v4 migration guidance, adds ingestion deprecation metadata, and removes SDK-log ingestion models.

  • Adds comment and legacy-observation time hints plus prompt-list filtering.
  • Documents new metadata-filter operators and real-time ingestion/read paths.
  • Adds _deprecation to legacy ingestion responses.
  • Introduces two compatibility problems: premature removal of public SDK-log types and an inaccurate claim that ingestion-version headers are already sent.
Diagram
%%{init: {'theme': 'neutral'}}%%
flowchart LR
    App[SDK caller] --> OTEL[OpenTelemetry ingestion]
    OTEL --> Header{x-langfuse-ingestion-version: 4}
    Header -->|present| Realtime[Real-time processing]
    Header -->|missing| Delayed[Potential delayed visibility]
    Realtime --> Obs[Observations API v2]
    Realtime --> Metrics[Metrics API v2]
    App --> Legacy[Legacy batch ingestion]
    Legacy --> Events[Typed ingestion-event union]
Loading

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

@github-actions

Copy link
Copy Markdown

@claude review

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


This endpoint implements the OTLP/HTTP specification for trace ingestion, providing native OpenTelemetry integration for Langfuse Observability.

Together with Observations API v2 and Metrics API v2, this is the only real-time write path. Other public API endpoints can delay data by about 10 minutes. Direct exporters must send `x-langfuse-ingestion-version: 4`; current Python and JS SDKs already do.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Required header is omitted

This documentation says current Python SDK requests already send x-langfuse-ingestion-version: 4, but neither this generated operation nor the SDK's default OTLP exporter adds that header. A caller following the documented export_traces API therefore misses the stated real-time-ingestion requirement and can see data delayed by about ten minutes. Either attach the header automatically or document and demonstrate how to provide it through RequestOptions.additional_headers.

Knowledge Base Used:

Prompt To Fix With AI
This is a comment left during a code review.
Path: langfuse/api/opentelemetry/client.py
Line: 41

Comment:
**Required header is omitted**

This documentation says current Python SDK requests already send `x-langfuse-ingestion-version: 4`, but neither this generated operation nor the SDK's default OTLP exporter adds that header. A caller following the documented `export_traces` API therefore misses the stated real-time-ingestion requirement and can see data delayed by about ten minutes. Either attach the header automatically or document and demonstrate how to provide it through `RequestOptions.additional_headers`.

**Knowledge Base Used:**
- [Generated API service domains](https://app.greptile.com/personal-org-4986/-/custom-context/knowledge-base/langfuse/langfuse-python/-/docs/generated-api-service-domains.md)
- [API compatibility and transport](https://app.greptile.com/personal-org-4986/-/custom-context/knowledge-base/langfuse/langfuse-python/-/docs/api-compatiblity-and-transport.md)

---

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

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment on lines +416 to 419
- `stringObject`: `"="`, `contains`, `does not contain`, `starts with`, `ends with`, `is set`, `is not set` (use `is set` / `is not set` for key presence; an empty value for `contains`, `starts with`, or `ends with` is treated as `is set`)
- `boolean`: `"="`, `"<>"`
- `null`: `is null`, `is not null`

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 (optional) The updated docstring for EvaluationRuleFilter_StringObject (line 416) tells callers stringObject filters now support is set/is not set operators, but the operator field at line 456 is still typed EvaluationRuleStringFilterOperator, whose enum (evaluation_rule_string_filter_operator.py) only defines =, contains, does not contain, starts with, ends with. Constructing EvaluationRuleFilter_StringObject(operator="is set", ...) as the new docs instruct raises a pydantic ValidationError, and parsing any GET response for an evaluation rule whose metadata/stringObject filter already uses is set/is not set server-side will fail the same way, breaking that read call. …

Why this was flagged

…Fix: regenerate/extend EvaluationRuleStringFilterOperator (or add a dedicated operator enum for stringObject) to include is set and is not set so both constructing requests and parsing responses with these operators succeed.

Trigger: an SDK user follows the new docstring at evaluation_rule_filter.py:416 and builds EvaluationRuleFilter_StringObject(column='metadata', key='k', operator='is set', value=''), or the Langfuse API (per the same spec update) returns an evaluation rule whose filter already uses is set/is not set, reached via GET/list evaluation rule endpoints in evaluation_rules/client.py that deserialize into EvaluationRuleFilter. The operator field at line 456 is pydantic-typed as EvaluationRuleStringFilterOperator, a strict enum in evaluation_rule_string_filter_operator.py that this diff did not update and that lacks these two literals. Base branch had no such docstring promise, so no user attempted this operator; after merge, both request construction and response parsing for it raise pydantic ValidationError, and no fallback or try/except catches this in…

Verification: nit. The docstring at evaluation_rule_filter.py:416 (changed by this diff, from "stringObject: same operators as string" to "...is set, is not set (use is set / is not set for key presence...)") advertises operators that the operator field cannot accept. Line 456 types operator as EvaluationRuleStringFilterOperator; that enum in evaluation_rule_string_filter_operator.py (unchanged by…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant