Truncate response errors vs swallowing if too large

[selzoc]

We found a case where the prepare step was running a vm out of disk, and there were many tar errors. The large amount of errors resulted in the agent returning "Response exceeded maximum allowed length" with no details, leading us to have to get onto the failing vm and examine the agent logs for more details.

This commit will attempt to truncate the error message to fit inside the max message length such that we can surface the error to the bosh task logs.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 3b299150-90f1-44d4-a16c-0056fa756c14

📥 Commits

Reviewing files that changed from the base of the PR and between feaf4eb and 9f80ff9.

📒 Files selected for processing (2)

• handler/perform_handler_with_json.go
• handler/perform_handler_with_json_test.go

---

Walkthrough

Adds UTF-8 boundary-aware truncation for exception response messages when marshaled JSON exceeds maxResponseLength. Introduces a truncationMarker constant and truncateExceptionResponse which probes JSON overhead with a marker, computes the remaining byte budget for the exception message, truncates the message at UTF-8 boundaries preserving head and tail around the marker while re-marshaling to account for escaping, and returns a modified exceptionResponse only if it fits. marshalResponse now attempts truncation for exception responses returned by response.Shorten() before falling back to the existing oversize error. Ginkgo tests cover behavior, UTF-8 correctness, escaping, fallback, and UnlimitedResponseLength.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: implementing truncation of response errors instead of completely omitting them when they exceed size limits.
Description check	✅ Passed	The description clearly relates to the changeset by explaining the problem context (VM out of disk, tar errors) and the solution (truncate errors instead of swallowing them).
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch truncate-perform-errors

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@handler/perform_handler_with_json_test.go`:
- Around line 93-113: Add a test to verify behavior when error messages contain
many JSON-escapable characters (quotes/backslashes) by calling
PerformHandlerWithJSON with a NewExceptionResponse whose error string is
strings.Repeat(`"`, maxLen) and assert the returned respBytes length is <=
maxLen; if truncation can't account for escaping, ensure the handler falls back
to a generic error payload instead of producing invalid/oversized JSON. Locate
the test near the existing UTF-8 truncation spec (the It block using
PerformHandlerWithJSON and NewExceptionResponse) and mirror its structure,
asserting either successful truncated JSON or the generic fallback response
while keeping utf8/json validity checks where appropriate.

In `@handler/perform_handler_with_json.go`:
- Around line 79-93: The truncation logic for excResp.Exception.Message assumes
byte-for-byte mapping to JSON, but json.Marshal can expand escapable characters;
fix by iteratively trimming and re-marshaling until the marshaled respJSON
length <= maxResponseLength: start with contentBytes (currently derived from
maxMsgBytes), slice msg to that length ensuring utf8.ValidString, set
excResp.Exception.Message = msg+truncatedSuffix, json.Marshal(excResp) and if
len(respJSON) > maxResponseLength reduce contentBytes (e.g., halve or decrement)
and repeat; ensure the loop breaks when contentBytes <= 0 and falls back to the
generic error path as before.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 7fe17c39-891c-4781-bce0-6fcae68aed94

📥 Commits

Reviewing files that changed from the base of the PR and between a590649 and feaf4eb.

📒 Files selected for processing (2)

• handler/perform_handler_with_json.go
• handler/perform_handler_with_json_test.go

[selzoc]

Marking as draft until I can test this on an actual vm