feat(api): update API spec from langfuse/langfuse 5b59af4 - #1895
langfuse-bot wants to merge 1 commit into
Conversation
|
@claude review |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.| - `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` | ||
|
|
There was a problem hiding this comment.
🟡 (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…
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.
_deprecationto legacy ingestion responses.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]Reviews (1) · Last reviewed commit: "feat(api): update API spec from langfuse..."