fix(health-twin): readJson must settle its promise on oversized payload

[mdheller]

Closes out a finding from Copilot's review on #932 (merged 2026-07-21).

req.destroy() with no error argument does not reliably emit 'error', so on a >2MB body the readJson promise never resolved or rejected — the request handler awaited it forever, a hung connection / resource leak on every oversized POST.

Fix: reject explicitly at the point of destroy() instead of waiting on an event that isn't guaranteed to fire. All call sites already wrap readJson in try/catch, so this turns a silent hang into the 400 those handlers already know how to send.

No automated test added: server.ts calls server.listen() at import time with no test-mode guard, so importing it in a node:test file would leave an open server handle and hang the test runner — a preexisting testability gap Copilot separately flagged on the same PR (no e2e coverage).

[Copilot]

Pull request overview

Note

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Fixes a hang/resource leak in readJson when an oversized request body is received by ensuring the returned promise always settles (rejects) instead of waiting for a non-guaranteed 'error' event after req.destroy().

Changes:

• Refactors readJson to explicitly reject when the payload exceeds 2MB.
• Adds a tooLarge guard to prevent later 'end'/'error' handlers from settling the promise after rejection.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (4)

apps/health-twin/src/server.ts:174

• MAX_BODY_BYTES is expressed in bytes, but raw.length measures UTF-16 code units (and raw += c will stringify Buffer chunks), so the effective limit can be inaccurate for multi-byte payloads. Track size using bytes (e.g., increment a byteCount by c.length when c is a Buffer, or use Buffer.byteLength(raw)), and only decode/stringify once after the full body is accepted.

const MAX_BODY_BYTES = 2_000_000;

apps/health-twin/src/server.ts:182

• MAX_BODY_BYTES is expressed in bytes, but raw.length measures UTF-16 code units (and raw += c will stringify Buffer chunks), so the effective limit can be inaccurate for multi-byte payloads. Track size using bytes (e.g., increment a byteCount by c.length when c is a Buffer, or use Buffer.byteLength(raw)), and only decode/stringify once after the full body is accepted.

      raw += c;

apps/health-twin/src/server.ts:187

• MAX_BODY_BYTES is expressed in bytes, but raw.length measures UTF-16 code units (and raw += c will stringify Buffer chunks), so the effective limit can be inaccurate for multi-byte payloads. Track size using bytes (e.g., increment a byteCount by c.length when c is a Buffer, or use Buffer.byteLength(raw)), and only decode/stringify once after the full body is accepted.

      if (raw.length > MAX_BODY_BYTES) { tooLarge = true; req.destroy(); reject(new Error(`payload too large (max ${MAX_BODY_BYTES} bytes)`)); }

apps/health-twin/src/server.ts:190

• When rejecting due to an oversized payload, it’s better to provide the same Error to req.destroy(err) rather than calling destroy() without an error. This helps ensure the connection is torn down in an error-aware way across Node versions and makes diagnostics more consistent, while still explicitly rejecting the promise immediately.

      if (raw.length > MAX_BODY_BYTES) { tooLarge = true; req.destroy(); reject(new Error(`payload too large (max ${MAX_BODY_BYTES} bytes)`)); }
    });
    req.on('end', () => { if (!tooLarge) { try { resolve(raw ? JSON.parse(raw) : {}); } catch (e) { reject(e); } } });
    req.on('error', (e) => { if (!tooLarge) reject(e); });