Skip to content

fix: return HTTP 413 for oversized panel requests - #424

Merged
StepenkoAnatoli merged 1 commit into
mainfrom
fix/issue-324-panel-413-response
Oct 16, 2026
Merged

StepenkoAnatoli merged 1 commit into
mainfrom
fix/issue-324-panel-413-response

Conversation

@StepenkoAnatoli

@StepenkoAnatoli StepenkoAnatoli commented Oct 16, 2026 •

Copy link
Copy Markdown
Owner

Fixes #324.

What changed

Oversized panel API requests now receive the existing JSON HTTP 413 refusal with Connection: close before the connection closes. Body handling releases retained chunks and ignores subsequent request data. The 16 KiB limit is unchanged.

Why

Destroying the request socket as soon as the limit was exceeded caused clients to receive a connection reset before the refusal could arrive.

What it touched

Panel request-body handling, two regression tests, architecture documentation, the changelog, and the registered test count.

What you verified

  • Verified: the original failure produced ECONNRESET; the corrected behavior returns HTTP 413 and JSON for 16,385-byte and 3 MB requests.
  • Verified: a 16,384-byte valid JSON request reaches routing, and a subsequent state request returns HTTP 200.
  • Verified: 26 focused tests passed with zero failures; two existing symlink cases were unsupported on this local Windows environment.
  • Verified: the normal full commit gate passed; corpus handoff and preflight checks passed.
  • Verified: all seven GitHub Actions jobs passed on commit b42ff91, including Windows, both Ubuntu platforms, Node 24/26, archive tree, and the aggregate suite. Node 24: 1847 passed, 0 failed in 195.3s (watchdog 60000ms/test).
  • Untested locally: the two unsupported symlink cases; CI provides the platform checks.

What you got wrong and fixed

Nothing to report.

what changed
Request-body overflow releases retained chunks and ignores subsequent data/end parsing. The handler sends the existing 413 JSON refusal with Connection: close, so the response flushes before closing the connection rather than destroying the request socket first.

why
Fixes #324. Destroying the request socket inside readBody prevented the handler's intended error response from reaching the client. This corrects response ordering under the existing byte limit; no new route, flag, format or check is introduced.

what it touched
research-kit/lib/panel.mjs; two panel regressions for an oversized POST and the exact byte boundary; the panel architecture row; CHANGELOG.md; the registered offline test count in research-kit/README.md (1847).

what you verified
verified: direct baseline loopback probe produced ECONNRESET for a 16385-byte JSON body, with the next state request returning 200.
verified: the fixed probe receives 413, Connection: close and {"error":"the request is too large"}; the next state request returns 200.
verified: boundary probe admits a complete 16384-byte JSON body to route handling (404 for the unknown test route), returns the intended 413 for 16385 bytes and 3 MB, then answers state with 200.
verified: node research-kit/bin/selftest.mjs panel passed 26 tests, 0 failed, with 2 existing unsupported symlink cases in 5.9s (LOCAL RESEARCH_KIT_ALLOW_UNSUP=1), including both new regressions.
verified: handoff OK (33 entries, 27 evidence rows), preflight PASS (28 passing, 1 existing unstamped-brief warning), and git diff --check. Cwd: C:\Users\PC\Desktop\gittoken\Research-Kit-issue-324.
verified: doctor today from the issue-296 checkout reports READY on the shared machine, collector role, firecrawl-cli fetch/search.
expected: the normal pre-commit gate will run the full staged-tree suite and validate architecture/README before this commit is recorded; exact-head CI will accompany the PR.
untested: local symlink creation is unavailable for two existing cases; CI must verify that capability. No external service or real operator panel was used; requests go only to disposable loopback servers with scratch machine state.

what you got wrong and fixed
nothing to report
@StepenkoAnatoli
StepenkoAnatoli merged commit a332996 into main Oct 16, 2026
7 checks passed
StepenkoAnatoli added a commit that referenced this pull request Oct 16, 2026
Preserve the eight reviewed source heads from #417 through #424 after all seven integration checks passed.
@StepenkoAnatoli
StepenkoAnatoli deleted the fix/issue-324-panel-413-response branch October 17, 2026 06:34
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.

panel: an oversized request body gets a dropped connection, not the 413 the code writes - readBody destroys the socket before the refusal is sent

1 participant