fix(api): make ctx.json() with no arguments read the request body (depends on #2999)

[mattboon]

Summary

ctx.json() in pages API routes looked like a request-body parser but actually built a JSON Response from undefined. Handlers that wrote const body = await ctx.json() received a Response object, and echoing it back serialized to {}, silently dropping POST payloads.

This PR makes ctx.json arity-based: ctx.json() parses the request body, while ctx.json(data, init?) still builds a JSON Response. The worker-isolation API path now uses the same helper so isolated and in-process handlers behave the same.

Verification

• deno test --allow-all src/routing/api/context-builder.test.ts
• deno task lint:sanitizer-baseline
• deno task lint
• deno task typecheck

Review status

Score: 94/100. Recommended next step: merge after GitHub required checks finish green.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 55aca343ea

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Implement ctx.json() in isolated pages routes

With WORKER_ISOLATION_ENABLED=1 and WORKER_ISOLATION_API=1, executePagesRoute() takes the isolated branch (src/routing/api/route-executor.ts:450), where src/security/sandbox/worker-script.ts:457 still builds ctx.json as only a response helper. A pages API handler using the newly supported await ctx.json() in that environment still receives a Response object instead of the parsed body, so POST payloads continue to be dropped under worker isolation; mirror this arity check in the worker context or share the same context builder there.

Useful? React with 👍 / 👎.

[kwakayama]

Score: 84/100

The tests show the intended arity split works: ctx.json() parses the request body, while ctx.json(data, init?) still builds a JSON response. This fixes a real footgun for handlers using the zero-arg form.

Not merge-ready yet:

• This is stacked on lower open PRs, including blocked/type-failing PRs.
• The PR status rollup only shows CLA, not full CI.

Architectural watch item: ctx.json now means request parsing or response creation depending only on arity. That may be pragmatic given existing usage, but it is a fragile public boundary and should be documented as an intentional overload.

[kwakayama]

Follow-up after fixes: approving. The public API docs now explain \ request parsing vs \ response creation, and examples were updated. I also scrubbed real-looking example names to synthetic test data. Score: 91/100. Next step: merge after base stack and checks are green.

[kwakayama]

Clean follow-up after the approval above:

Score: 91/100.

Fix added: public docs now explain ctx.json() request parsing vs ctx.json(data, init?) response creation. I also scrubbed real-looking example names to synthetic test data.

Next step: merge after the base stack and refreshed checks are green.

The base branch was changed.

[kwakayama]

Score: 94/100

Critical review result: this fixes a real API-route bug. await ctx.json() previously returned a JSON Response built from undefined, so handlers that intended to parse POST JSON silently received a Response object and often serialized {} back to the client. The arity overload is narrow, keeps ctx.json(data, init?) response behavior intact, and covers the sandbox worker path by sharing the helper.

Validation reviewed:

• deno test --allow-all src/routing/api/context-builder.test.ts
• deno task lint:sanitizer-baseline
• deno task lint
• deno task typecheck

Recommended next step: merge after GitHub required checks complete green.