-
[OPIK-7336] [DOCS] Document span/trace ingestion size limits + attachments (#7468)
frostbyte_neo 发布于
2026-07-22 08:13:57 +00:00 - docs(faq): document span/trace ingestion size limits + attachments
Add two FAQ entries in the Latest-version docs (docs-v2/faq.mdx):
- "Is there a limit on how large a trace or span can be?" covering the
per-field (~20 MB) and per-request (~50 MB compressed / ~256 MB
uncompressed) limits, and pointing to Attachments for large payloads. - "Why am I getting a 413 error?" troubleshooting entry.
Documents the limits from OPIK-7312 (OPIK-6999 / OPIK-7273). Values are
pending final confirmation of the shipped enforcement.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- docs: add Size limits section to attachments page + address review (OPIK-7336)
- Add a "## Size limits" section to log_multimodal_traces.mdx (per Nimrod) so
the FAQ can deep-link to #size-limits, and the attachments page itself
explains the per-field/per-request limits and positions attachments as the fix. - Point the FAQ "attachment" links at #size-limits.
- Soften the SDK-truncation wording (per Baz): scope it to recent SDK versions,
describe the marker, and clarify the client-side truncation addresses oversized
single spans (a large batch can still be rejected).
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- docs: disambiguate inline vs base64 size limits (OPIK-7336)
Resolve the two-numbers-for-one-contract conflict Baz flagged: the ~20 MB
per-field / ~50 MB-compressed request limits apply to inline (non-media)
content, while a single base64 media value can be up to 100 MB because the SDK
extracts anything >~250 KB and uploads it as a separate attachment (not part of
the JSON ingestion request). Add a base64-exemption note + cross-reference, and
rename the downstream "Size Limits" heading to "Embedded base64 size limits" so
the two sections no longer collide on the #size-limits anchor.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- docs: only input/output are truncated client-side, not metadata (OPIK-7336)
Align the size-limits docs with the SDK change (OPIK-7335 / OPIK-7349): the
client-side ~20 MB truncation applies to input/output only. metadata is not
truncated; it still counts toward the per-request limit, so an oversized
metadata is rejected (413/400) rather than trimmed. Base64 attachment
extraction still covers input/output/metadata and is unchanged.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- docs: de-duplicate size limits - FAQ summarizes + links to canonical section (OPIK-7336)
Baz review ("duplicate limit notice"): the FAQ repeated the per-field/per-request
size-limit bullets already in log_multimodal_traces.mdx#size-limits, so the
numbers had to be maintained in two places and could drift. Make that multimodal
section the single canonical source; the FAQ now gives a qualitative answer and
links to it, and the 413 troubleshooting entry links instead of restating the
number. The exact figures (~20/50/256 MB) now live in exactly one place.Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- docs: align size-limits with the SDKs — span+trace truncation, base64 formats (OPIK-7336)
Reflect the shipped SDK behavior:
- truncation applies to spans AND traces (both SDKs), not just spans
- base64 extraction covers images/audio/video/PDF and other recognized formats
such as JSON, not only "media" - note the ~20 MB per-field cap also applies to input+output combined
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
- docs: size-guard rejections return 413, not 413/400 (OPIK-7336)
The backend now normalizes an oversized-document / oversized-string rejection
(StreamConstraintsException) to 413 REQUEST_ENTITY_TOO_LARGE, matching the request-size
filter. Update the FAQ and the multimodal size-limits section to state a single 413
instead of "413/400".Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
Co-authored-by: Claude Opus 4.8 (1M context) noreply@anthropic.com
下载附件