update_issue body is capped at 10 KB while create_issue / add_comment allow 65 KB

[sg650]

update_issue body is capped at 10 KB while create_issue / add_comment allow 65 KB

Summary

The update_issue safe-output rejects any body larger than 10 KB with a JSON-RPC
validation error, even though the handler-level validation already permits up to
MaxBodyLength (65000). The sibling outputs create_issue and add_comment accept
bodies up to 65536. The discrepancy comes from a single missing maxLength on the
update_issue.body property in the MCP tool input schema.

Observed on v0.82.x; the schema omission is still present on main at time of writing.

Reproduction

A scheduled/dispatch workflow that maintains a large "dashboard" issue by replacing its
body each run:

---
on:
  workflow_dispatch:
permissions:
  contents: read
  issues: write
engine: copilot
safe-outputs:
  update-issue:
    target: "*"
    body:
---

# Repro

Call `update_issue(issue_number=<N>, operation="replace", body="<Markdown body larger than 10 KB>")`
— e.g. a generated table that renders to ~12 KB.

Expected: the issue body is replaced (up to the documented ~65 KB limit).

Actual: the call is rejected before it reaches the handler:

-32602: Input string parameter(s) exceed the 10 KB limit for tool 'update_issue': 'body' (11899 bytes)

The identical body submitted via create_issue or add_comment succeeds. (A body under
10 KB updates fine, which is why this only surfaces once the content grows.)

Root cause

The MCP call-time validator validateStringInputLengths
(actions/setup/js/mcp_scripts_validation.cjs) applies a 10 KB default cap
(MAX_STRING_INPUT_BYTES = 10 * 1024, "SM-IS-01") to every top-level string argument —
but explicitly skips any field that declares its own maxLength:

// Skip fields with an explicit maxLength — handler-level validation enforces their limit.
if (typeof schema.maxLength === "number") {
  continue;
}

In the tool input schema (actions/setup/js/safe_outputs_tools.json, generated from
pkg/workflow/js/safe_outputs_tools.json), the body field declares maxLength for some
issue-writing tools but not for update_issue:

tool	body.maxLength in tool schema	subject to 10 KB pre-check?
create_issue	65536	no (skipped)
add_comment	65536	no (skipped)
update_issue	(absent)	yes → capped at 10 KB

Because update_issue.body has no maxLength, it falls through to the 10 KB default and is
rejected at MCP-call time — before it ever reaches the handler. The handler-level config
already allows the full body length: pkg/workflow/safe_outputs_validation_config.go
defines update_issue.body as {Type: "string", Sanitize: true, MaxLength: MaxBodyLength}
(65000), identical to create_issue and add_comment. So the 10 KB rejection is purely an
artifact of the missing schema annotation, not an intended limit for issue bodies.

The error surfaces from actions/setup/js/mcp_server_core.cjs (and the HTTP transport
mcp_scripts_mcp_server_http.cjs), which call validateStringInputLengths(args, tool.inputSchema).

Implementation plan

1. Add maxLength to update_issue.body in the tool schema
   (pkg/workflow/js/safe_outputs_tools.json, and regenerate/mirror
   actions/setup/js/safe_outputs_tools.json):

   • Set body.maxLength to 65536, matching create_issue and add_comment.
   • This makes validateStringInputLengths skip the 10 KB default for update_issue.body,
     deferring to the handler-level cap (MaxBodyLength = 65000) that is already enforced.

2. Add regression coverage
   (actions/setup/js/safe_output_type_validator.test.cjs or the nearest existing
   validation test):

   • Assert an update_issue call with a body between 10 KB and 65 KB is accepted at
     MCP-call time (no -32602).
   • Assert a body over the handler-level MaxBodyLength is still rejected (by the
     handler), so the real cap is unchanged.
   • Optionally, a schema-consistency test asserting every issue/comment-writing tool that
     declares a body string field also declares body.maxLength, to prevent regressions
     for other tools.

3. Follow project guidelines

   • Run make agent-finish (or the repo's equivalent) before completing.
   • Keep the change scoped to the schema + tests; no change to MAX_STRING_INPUT_BYTES or
     the validator logic is needed — the skip path already exists.

Suggested labels

bug, mcp

[pelikhan]

/scout this issue should be fixed now.

[github-actions]

🔭 Recon complete! Scout has charted the territory. Map ready! 🗺️

[github-actions]

🔍 Scout Research Report

Triggered by @github-actions[bot]

Executive Summary

I verified this bug report against the current main, and the described fix is already in place — the report's premise ("the schema omission is still present on main") no longer holds. update_issue.body now declares maxLength: 65536 in both the source schema and its generated mirror, exactly as the implementation plan's step 1 prescribes. The remaining, still-actionable work is the regression/schema-consistency test (plan step 2), which does not yet exist — and which would catch one residual omission I found: update_issue.title still has no maxLength.

Click to expand detailed findings

Research Findings

The primary fix is already merged

update_issue.body carries "maxLength": 65536 in both files the plan targets:

• pkg/workflow/js/safe_outputs_tools.json (source of truth)
• actions/setup/js/safe_outputs_tools.json (generated mirror)

matching create_issue and add_comment (both 65536). So update_issue.body now takes the validator's skip path and defers to the handler cap.

Validator logic matches the report exactly

validateStringInputLengths in actions/setup/js/mcp_scripts_validation.cjs:

• MAX_STRING_INPUT_BYTES = 10 * 1024 (SM-IS-01), applied to string args with no maxLength.
• Fields with maxLength are enforced by character count and skip the 10 KB byte cap (the if (typeof schema.maxLength === "number") { ... continue; } branch). This is the exact mechanism the report identified.

Handler-level cap unchanged

pkg/workflow/safe_outputs_validation_config.go: MaxBodyLength = 65000, and update_issue is registered with a body field using that cap — so the real limit (~65 KB) is intact and now actually reachable.

Test coverage — partial

actions/setup/js/mcp_scripts_validation.test.cjs unit-tests the skip-on-maxLength behavior generically (incl. a case where body has maxLength and a maxLength-less title falls back to the 10 KB default). However, there is no test that (a) asserts an update_issue body between 10–65 KB is accepted at MCP-call time, nor (b) a schema-consistency test asserting every body-writing tool declares body.maxLength. Plan step 2 remains unimplemented.

Residual inconsistency worth noting

update_issue.title has no maxLength, so it is still subject to the 10 KB byte pre-check — the same class of omission this issue is about. Low practical impact (titles rarely exceed 10 KB), but exactly what the plan's optional schema-consistency test would surface.

Recommendations

• Verify and close: the body fix is present on main; a maintainer should confirm on the reported v0.82.x→current path and close if satisfied (the issue is still OPEN with no linked PR in its timeline).
• Land the remaining test work (plan step 2): add a regression test for a 10–65 KB update_issue body accepted at call time + rejected only above MaxBodyLength, plus a schema-consistency test across body-writing tools.
• The consistency test would flag update_issue.title lacking maxLength — decide whether to annotate it too.

Key Sources

• pkg/workflow/js/safe_outputs_tools.json / actions/setup/js/safe_outputs_tools.json (schemas)
• actions/setup/js/mcp_scripts_validation.cjs (validator, SM-IS-01)
• pkg/workflow/safe_outputs_validation_config.go (MaxBodyLength = 65000)
• actions/setup/js/mcp_scripts_validation.test.cjs (existing tests)

Suggested Next Steps

1. Reproduce with a >10 KB update_issue body on current main to confirm the -32602 no longer fires.
2. If confirmed, add the missing regression + schema-consistency tests, then close the issue.

🔭 Intelligence gathered by Scout · 82.4 AIC · ⌖ 12.2 AIC · ⊞ 6.4K · ◷
_{Comment /scout to run again}