Skip to content

Return typed HTTP statuses on OTLP ingest errors#7

Open
phall1 wants to merge 1 commit into
kitlangton:mainfrom
phall1:better-500-errors-on-ingest
Open

Return typed HTTP statuses on OTLP ingest errors#7
phall1 wants to merge 1 commit into
kitlangton:mainfrom
phall1:better-500-errors-on-ingest

Conversation

@phall1

@phall1 phall1 commented Apr 22, 2026

Copy link
Copy Markdown

Before: every /v1/traces and /v1/logs failure (eg a protobuf-payload exporter, a malformed body, a downstream worker panic) collapsed into a generic 500 Internal Server Error with an empty body.

This made protocol mismatching debugging opaque. I was sending OTLP/HTTP-protobuf, and the clankers didn't have a hint that motel implements only the JSON encoding.

should this be added?

Now the predictable failure modes map to informative statuses:

415 Unsupported Media Type — Content-Type isn't application/json (protobuf payloads hit this -> body names the fix: protocol=http/json).

400 Bad Request — body is JSON but unparseable.

500 Internal Server Error — genuine downstream failures (unchanged).

The classification is extracted into src/otlpIngestResponse.ts so the Content-Type / error-message branches are unit-testable without an HTTP runtime. 13 new tests

Before: every `/v1/traces` and `/v1/logs` failure — a protobuf-payload
exporter, a malformed body, a downstream worker panic — collapsed into
a generic `500 Internal Server Error` with an empty body. That made
protocol-mismatch debugging opaque; a caller sending OTLP/HTTP-protobuf
(the SDK default on most platforms) had no hint that motel implements
only the JSON encoding.

Now the predictable failure modes map to informative statuses:

  415 Unsupported Media Type  — Content-Type isn't application/json
                                 (protobuf payloads hit this; body
                                 names the fix: protocol=http/json).
  400 Bad Request             — body is JSON-claimed but unparseable.
  500 Internal Server Error   — genuine downstream failures (unchanged).

The classification is extracted into `src/otlpIngestResponse.ts` so the
Content-Type / error-message branches are unit-testable without an HTTP
runtime. 13 new tests; full suite remains green (170/170).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@phall1 phall1 marked this pull request as ready for review April 22, 2026 08:07
@sms-swe

sms-swe commented Apr 24, 2026

Copy link
Copy Markdown

This improves the error handling, but I think the underlying root cause is that default OTLP/HTTP exporters send application/x-protobuf. I opened #8 to address that directly by accepting protobuf payloads in addition to JSON.

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.

2 participants