Tracing ingest: `OTelLinksResponse.count` over-counts and writes a removed `dropped` field

[mmabrouk]

Summary

POST /tracing/spans/ingest and POST /traces/ingest build their response with count = len(links) + len(dropped) and pass dropped=dropped or None. Both lines are out of step with the response model:

• OTelLinksResponse no longer declares a dropped field (see api/oss/src/apis/fastapi/tracing/models.py). The dropped=... kwarg is silently ignored on serialisation.
• count is documented in the model and the tracing concept page as "the number of spans accepted and published to the stream". With dropped added in, the response over-reports acceptance and hides partial failures from the caller.

Repro

api/oss/src/apis/fastapi/tracing/router.py:296 (around ingest_spans):

link_response = OTelLinksResponse(
    count=len(links) + len(dropped),
    links=links,
    dropped=dropped or None,
)

Submit N spans where K fail at parse time. The response returns count = N (including the K dropped) and only len(links) = N - K entries under links, but the caller cannot detect the discrepancy because dropped is no longer in the serialised body.

Fix

link_response = OTelLinksResponse(
    count=len(links),
    links=links,
)

Or, if surfacing dropped spans to the caller is desirable, reintroduce a dropped field on OTelLinksResponse and document it.

Where to look

• api/oss/src/apis/fastapi/tracing/router.py:288-300
• api/oss/src/apis/fastapi/tracing/models.py:108-133 (the OTelLinksResponse model)
• The same pattern is used inside ingest_traces on the deprecated router. Whatever the fix here, mirror it there.

Context

Surfaced during the #4172 API reference docs pass. CodeRabbit flagged the same mismatch in PR #4314. The bug fits the silent-failure-on-ingest family along with #4172 / #4173 / #4315.

Holding off on touching this in the docs PR (#4314) since it is a business-logic change with its own test surface. Filing here for a focused fix.

[linear-code]

AGE-3758