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

[polylane]

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"

Loading

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.}

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 79e9edf0-07c4-4681-9d5c-bff65e06c538

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

React Doctor found no new issues. 🎉

_{Reviewed by React Doctor for commit e0d3a27.}

[polylane]

Tip

Expected to resolve the linked issue.

Linked issue: iss_11c99c80f0015974uq22x87h — liteparse container logs its readiness probe as a request error

Checked the added GET / branch in containers/liteparse/server.mjs against the live liteparse container: it answers only the readiness probe and leaves every parse path unchanged. In 7 days, 286 of 288 error events are that probe's 404; 2 are real extraction errors.

View the full analysis →

Also considered · 2 refuted

• Refuted · Answering the readiness probe with 200 hides a dead parser from the container runtime · Readiness was already satisfied by the 404, so the readiness decision does not change; the diff only changes the status the app itself logs.
• Refuted · The new GET / route swallows a path a real consumer depends on · The only observed caller of GET / is the runtime readiness probe (286 of 286 GETs over 7 days, arriving in startup bursts); the observed caller set produces no other use of that route.

Analysed against 2 Cloudflare Workers and 1 repository

• Cloudflare Workers: thinkex, thinkex-staging
• Repository: ThinkEx-OSS/thinkex

_{Polylane analysed e0d3a27 for production impact. You can ask follow-ups by mentioning @polylane in a comment.}

Rate this review: 👍 helpful · 👎 not helpful · 😕 confusing

Suggested observability improvements

These are advisory and do not affect the production-impact verdict. Review them on this branch when convenient:

After this change the readiness probe is logged as a successful liteparse_request, indistinguishable from a real extraction in the same event. Over the 7 days read, the probe contributed 286 of ~570 liteparse_request events, so the success ratio now carries probe traffic. Add a field such as readiness_probe: true to the event the finally block emits in containers/liteparse/server.mjs so an operator can separate probe traffic from real extraction outcomes when they read the container's success and error rates.

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Adds a readiness probe handler to a container service.

Safe to merge. The readiness response and request logging work as intended, and the tested route errors and capacity protections remain intact.

What we checked:

• Readiness probes leave capacity unchanged: The readiness branch returns before taking a parse slot. The cleanup code releases a slot only when this request holds one.
• Validated that GET / with Host: ping returned 404 Not Found before changes and returned 200 OK with a status of ok after changes.
• Verified that GET /unknown and POST / continue to return 404 Not Found, confirming errors are not masked by the new branch.
• Observed extractor capacity behavior under concurrent POST /parse/pdf requests: when two requests remain open, a subsequent request returns 503 Extractor is at capacity, both before and after the changes.
• Captured server run artifacts to support verification, including the executed server source, command, working directory, exit code, and request/response logs.

T-Rex evidence

Evidence from the check

• This executed script starts parent or unchanged head source and asserts real HTTP responses against stdout logs, making the scoped comparison reproducible.

Command output from the check

• Ran parent source through the idle and saturated probes, showing readiness returned 404 errors while negative routes and capacity rejection remained intact.

Command output from the check

• Ran unchanged head through identical probes, showing readiness returned 200 success without masking tested route errors or changing capacity rejection.

Summary

Adds a successful response for GET / so readiness probes no longer appear as request errors.

• Runtime-style probes with Host: ping and ordinary GET / requests returned HTTP 200 with {"status":"ok"} and were logged as successful requests.
• Unknown routes and POST / continued to return HTTP 404 and were logged as errors.
• Readiness probes remained successful with both parse slots occupied. Additional parse requests continued to receive HTTP 503 before and after the probes, confirming that capacity handling remains unchanged.
• No actionable issues found. The change is safe to merge.

_{Reviews (1) · Last reviewed commit: "fix(liteparse): answer the container rea..." · Reviewed by Greptile}