docs: state the Comfy Router request-body cap on the limits page - #1697
Conversation
Router's cap on the whole request body was not stated on any Router page, so a caller planning an inline-media call had nowhere to learn the bound before hitting it. The only size figure they could find was the provider's own per-field 'Size limit: 20MB' on the Google model pages, which is Google's bound on its inlineData.data field rather than Router's bound on the request body. State the cap once on the capabilities-and-limits page: the byte figure, the base64 4/3 consequence, what the 413 invalid_input refusal looks like, that it does not depend on sending an Idempotency-Key, and that a provider's own lower limit binds first when it is smaller. The shared model-code footer now points every generated model page at that section and says plainly that a field description's size limit is the provider's, not Router's, so the provider text stays verbatim.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
🌐 i18n translation sync reminder@comfyui-wiki English documentation was updated in this PR. Please complete or schedule translation updates for the following files: Japanese (
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe documentation adds a 10 MiB request-body limit for Router requests. It documents pre-dispatch ChangesRouter body limits
Suggested reviewers: Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to The documentation matches the Router API contract, with no current merge-blocking risk. 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
1 participant
ELI-5
A partner sent a big reference image through Comfy Router and got a
413back. They went looking for the size limit in our docs and found a "20MB" on the Google model pages, so they thought Router had broken its own promise. Two things were wrong: no Router page stated a request-body limit at all, and the only number a reader could find was Google's limit on Google's own field, not ours on the whole request. This PR states Router's limit once, on the capabilities-and-limits page, and makes every model page's footer point at it while saying plainly that a size limit in a field description belongs to the provider.What changed
development/comfy-router/limitations.mdxgains a Request bodies are capped section covering the byte figure, the base64 consequence (encoding inflates by about 4/3), what the refusal looks like (413withinvalid_inputonX-Comfy-Error-Type), that the cap does not depend on sending anIdempotency-Key, and that a provider's own lower bound on inline media binds first when it is the smaller of the two. A row in the page's "What Router supports" table links into it so a reader planning an inline-media call meets the bound in the summary rather than in production.snippets/comfy-router/model-code-footer.mdxgains a pointer to that section plus one sentence disambiguating the provider text: a size limit named in a field description is the provider's bound on that field, and Router's cap on the whole body is separate. The footer is the right hook because the generator has none for a per-provider note.renderPageand the derived-page renderer both emit<RouterCodeFooter />unconditionally and the template carries no per-provider note field, so the alternative was editing the 11 provider schemas whose descriptions are copied verbatim on purpose. No schema was touched and no generated.mdxwas hand-edited. Because the footer renders on all 204 model pages rather than only the 8 Google ones, the pointer also covers the other providers that quote a size figure (see the sweep below).Why the figure is the current one, not the raised one
The raise to 20 MiB is merged but, per the work item driving this, not yet deployed. The page therefore states the figure that is live today and tells the reader to treat what the API returns as authoritative if the two ever disagree. Swapping the two numbers when the raise deploys is a one-line edit; it is called out under Residual below.
I could not confirm the live figure by observation from this environment. Authentication is evaluated before the body-size gate: an unauthenticated
POST /v2/models/vertexai/gemini-2.5-flashcarrying an 11,534,393-byte body (above the current cap, below the raised one) uploaded in full and came back401 No Authorization header found, not413. With no Comfy credential available here there is no path to a413observation, and I did not go looking for someone's key to make one. The empirical basis for the denial being real is the reporter's own413quoted on the work item; the empirical basis for which bound is live is not mine.Corpus sweep
Size limit: 20MBappears 16 times across exactly 8 Google model pages and nowhere else indevelopment/comfy-router/models/, which matches the reported scope. Sweeping the portion this PR does not rewrite: 49 of 204 model pages quote some provider size figure, so 41 pages across 9 other providers (wan18,byteplus8,kling7,moonvalley2,gemini-interactions2,tencent,runway,black-forest-labs,beeble1 each) carry the same class of provider-versus-Router ambiguity. None of those 41 is edited here, and none needs to be: the footer sentence is provider-neutral and renders on every one of them.No conflicting figure exists elsewhere.
api.mdx,headers.mdx,models.mdx,queue.mdxandquickstart.mdxstate no body-size figure;reference.mdxcarries413on both the synchronous and the queued route with the wording "The request body is too large" and no number, which is what the new section's "applies to both delivery modes" claim is grounded in.reference.mdxandmodels.mdxare generated and were left alone.Provenance
python3 .github/scripts/check-anchors.py --only-changed: 3 files, all anchor links OK (falsified by temporarily corrupting the new anchor, which the check caught and named the correct slug for);python3 .github/scripts/validate-links.py: 6147 files, all link validations passed;npx mint broken-links: no broken links found;bun run code-pages:check: 204 code pages fresh (27 curated, 177 derived);bun test ./.github/scripts/snippets/: 30 pass, 0 failResidual
The byte figure needs one edit when the request-body raise deploys. The section states the currently live cap, 10 MiB (10,485,760 bytes) and roughly 7.5 MB of actual media bytes. When the raise ships, both figures in
development/comfy-router/limitations.mdxbecome 20 MiB (20,971,520 bytes) and roughly 15 MB. At that point the provider paragraph should also gain the worked comparison named under Deviations above: Google's 20 MB decimal limit becomes the smaller of the two, so a body between 20,000,000 and 20,971,520 bytes is refused by Google rather than by Router.The live figure is unverified from this environment. Nothing in this PR observed a
413. The probe above establishes only that auth precedes the size gate, so a credentialed check is still owed before the number on this page is treated as confirmed rather than as carried over from the report.The
ja,koandzhcopies of this page do not carry the new section. The i18n sync check flagsja/ko/zh development/comfy-router/limitations.mdxand, separately,snippets/{ja,ko,zh}/comfy-router/model-code-footer.mdx. The snippet half is a pre-existing gap rather than one this PR opens: no localized copy ofsnippets/comfy-router/exists for any locale today. The page half is also already divergent independently of this change. The three locale files are translations of an older structure (10 sections, headed "No queued submission", "Three forecast buckets are not in the vocabulary" and so on) while the English page has since been rewritten to a different structure entirely, so they were stale before this commit. Translation is a separate pipeline in this repo and needs an API key not available here, so it is left to that pipeline; the sync check is a warning and does not fail the build.Remediation guidance for a body that is too large is deliberately absent. The section tells a reader what the bound is and what the refusal looks like, but not what to send instead. The URL-versus-base64 and self-hosted guidance belongs to the parked image-to-image guide work, along with the
example.invalidplaceholder on thewan2-5-i2i-previewgenerated page, and neither is touched here.Unexercised artifacts. The change to the cap itself lives in a separate private repository and was not read; its state (merged, not deployed) is taken from the work item rather than verified. No related item, attachment or sub-issue was readable from this environment.