#854 fix(liteparse): answer the container readiness probe so it is not logged as an error

Fixes: Liteparse container logs its readiness probe as a request error, reporting ~50% false errors

The liteparse container reported roughly half of its requests as errors, but almost all of those were the Cloudflare Containers runtime checking that the container port is ready. The container answered that probe with 404 and recorded it as a failure, so its error telemetry was unusable and raised a false capacity alarm while 99.3% of real extraction requests succeeded. After this change the container answers the readiness probe with 200, so it counts as a served request and the error signal reflects real extraction outcomes.

sequenceDiagram
    participant DO as WorkspaceFileProcessor (DO)
    participant RT as "@cloudflare/containers runtime"
    participant S as "liteparse server.mjs"
    RT->>S: "GET http://ping/ (readiness probe, path /)"
    Note over S: before: no / route, logged outcome=error
    S--)RT: "404 Not found"
    Note over S: after fix: GET / answered
    S--)RT: "200 status ok, logged outcome=success"
    DO->>S: "POST /parse/pdf, /prepare/pdf, /preview/image"
    S--)DO: "200 result, or 422/503 real outcome"

Detection evidence

Affected: acc_0ffb6c6e7001s4bfa5fafx1t

Why this fix

The @cloudflare/containers runtime probes the port with GET http://ping/ before routing work, and treats any response as the port being ready (dist/lib/container.js:342,664). The container has no / route, so it returned 404 and its request logger mapped that to outcome=error (server.mjs:139). In the 7 days to 2026-10-08T17:34Z, 286 of 288 error events were exactly this probe; real endpoints succeeded 274/276. Answering GET / with 200 makes the probe a served request, so the error ratio now reflects actual extraction failures. Capacity settings are unchanged and the 503 load-shed path is untouched.

Fix walkthrough

Watch the fix explained (2:47). Recorded for commit e0d3a27c8192a970e0a18f8c51a6fb309ca8ec91.

Causal chain

• Signal (log template): event=liteparse_request outcome=error for method=GET path=/ status=404
• Surfacing site: thinkex-liteparsepdfextractor-production (container application a0330fb5-c14e-44a2-bdd6-96077721cf1a) at containers/liteparse/server.mjs#handleRequest (request logger)
• Mechanism: The @cloudflare/containers runtime calls waitForPorts before routing work, which fetches http://ping/ (path /). The container has no / route, so it returns 404, and the request logger maps any status >= 400 to outcome=error, so 286 of 288 seven-day error events are this healthy readiness probe.
• Producer: liteparse container server request logging (thinkex repo), at containers/liteparse/server.mjs#handleRequest
• Trigger: Every startAndWaitForPorts call by the WorkspaceFileProcessor Durable Object
• What happens to the failed unit today: waitForPorts retries until any non-throwing response on the port, ignoring HTTP status, so a 404 satisfies readiness but is still logged by the app as an error.
• Cadence check: 7-day window: 286 probe 404s vs 281 successes; 24h window: 36 errors/34 successes.
• Blast radius: 0 other resource(s), 0 other tenant(s); data at risk: none named
• Producer evidence:
  • containers/liteparse/server.mjs:66-68 returns 404 for non-POST-parse routes
  • containers/liteparse/server.mjs:139 logs outcome: status < 400 ? success : error
  • @cloudflare/containers@0.3.7 dist/lib/container.js:342 pingEndpoint='ping', :664 tcpPort.fetch('http://'+pingEndpoint) treats any response as ready
  • telemetry: 7d error GET / 404 = 286, success 200 = 281, error POST /parse/pdf 503 = 2

1 file changed (+8/-0)

• containers/liteparse/server.mjs: modified, +8/-0

---

Generated by Polylane. You can ask follow-ups by mentioning @polylane in a comment.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}