feat(api): update API spec from langfuse/langfuse 9d08464

[langfuse-bot]

Greptile Summary

This PR updates generated API clients to support optional timestamps that narrow comment-reference validation and legacy observation lookup.

• Adds object_start_time to synchronous and asynchronous comment creation clients and request models.
• Adds start_time as an optional query parameter for synchronous and asynchronous legacy observation retrieval.
• Preserves existing behavior when either timestamp is omitted.

Confidence Score: 5/5

The PR appears safe to merge with no actionable correctness, security, or repository-rule issues identified.

Both timestamp additions follow existing generated-client conventions, preserve omission semantics, and are wired consistently through synchronous and asynchronous paths.

_{Reviews (1): Last reviewed commit: "feat(api): update API spec from langfuse..." | Re-trigger 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.}

[claude]

Looks good, straightforward additive API client change.

What was reviewed: the five auto-generated Fern client files adding optional object_start_time/start_time datetime parameters to Comments.create() and legacy ObservationsV1.get(). Confirmed the new params are wired through sync/async client, raw client, and (for comments) the pydantic request model, following the same patterns already used for existing optional fields (OMIT defaults, FieldMetadata alias, serialize_datetime for query params). No existing behavior is removed or altered.

Extended reasoning...

Overview

This PR touches five auto-generated (Fern) API client files under langfuse/api/comments/ and langfuse/api/legacy/observations_v1/. It adds two new optional datetime parameters: object_start_time on the Comments create() method (sync client, async client, raw client, and the CreateCommentRequest pydantic model), and start_time on the legacy Observations V1 get() method (sync client, async client, raw client). Both are purely additive — new optional keyword arguments defaulting to OMIT/None, plumbed into request bodies (comments, via the JSON body) or query strings (observations, via serialize_datetime), with corresponding docstring updates.

Security risks

None identified. These are typed pass-through parameters (datetime objects) serialized via the existing, already-audited serialize_datetime helper and the existing JSON body serialization path (omit=OMIT). There is no new parsing, deserialization of untrusted input, auth logic, or dynamic code execution introduced. The values originate from the SDK caller, not from any external/untrusted source within this diff.

Level of scrutiny

Low. This is exactly the kind of small, mechanical, auto-generated additive change (new optional parameter added consistently across all layers of a generated client) that matches long-established patterns already present in the same files (e.g. author_user_id in comments, other query params in the raw observations client). I verified the full diff line-by-line and confirmed every change is additive with no removed or altered existing behavior, and no divergence between the PR description and the actual diff.

Other factors

No CLAUDE.md conventions apply. No CODEOWNERS restriction found for these paths. The bug-hunting system reported zero findings, and my own reading of the diff turned up nothing beyond what's already obvious from the mechanical nature of the change. There is no prior review history on this PR to reconcile with.