Skip to content

fix(gmail-setup): use truncateUtf16Safe for gmail setup output truncation#102719

Closed
zhangqueping wants to merge 1 commit into
openclaw:mainfrom
zhangqueping:fix/utf16-safe-gmail-setup
Closed

fix(gmail-setup): use truncateUtf16Safe for gmail setup output truncation#102719
zhangqueping wants to merge 1 commit into
openclaw:mainfrom
zhangqueping:fix/utf16-safe-gmail-setup

Conversation

@zhangqueping

Copy link
Copy Markdown
Contributor

What Problem This Solves

The Gmail setup utility uses a raw UTF-16 code-unit slice to truncate command output at 800 chars. An emoji crossing the boundary could produce an unpaired surrogate in error messages or debug output.

Why This Change Was Made

Replace .slice(0, MAX_OUTPUT_CHARS) with truncateUtf16Safe in trimOutput. The existing limit and ellipsis suffix remain unchanged.

Files Changed

File Change
src/hooks/gmail-setup-utils.ts Replace raw .slice(0,N) with truncateUtf16Safe in trimOutput.

🤖 Generated with Claude Code

…tion

Replace raw UTF-16 slice in trimOutput with truncateUtf16Safe to
prevent surrogate pair splitting in Gmail setup command output.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
@openclaw-barnacle openclaw-barnacle Bot added size: XS triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jul 9, 2026
@clawsweeper

clawsweeper Bot commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge. Reviewed July 9, 2026, 7:41 AM ET / 11:41 UTC.

Summary
The branch imports truncateUtf16Safe and uses it when truncating Gmail setup command stdout/stderr in src/hooks/gmail-setup-utils.ts.

PR surface: Source +1. Total +1 across 1 file.

Reproducibility: yes. Source inspection gives a high-confidence path: current main slices stdout/stderr at 800 UTF-16 code units, so output with a surrogate pair crossing that boundary can produce an unpaired surrogate; I did not run the live Gmail setup flow.

Review metrics: none identified.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • [P1] Add redacted after-fix proof showing the Gmail setup output/error truncation path, such as terminal output, logs, or a reproducible CLI transcript.
  • Consider adding a focused Gmail setup utility test for a surrogate pair crossing the 800-code-unit boundary.

Proof guidance:

  • [P1] Needs real behavior proof before merge: Missing: the PR body/comments have no after-fix Gmail setup terminal output, logs, or reproducible CLI transcript; the contributor should add redacted proof and update the PR body for re-review.

Risk before merge

  • [P1] No contributor-owned after-fix proof shows the Gmail setup stdout/stderr error path using the new truncation behavior.
  • [P1] The helper itself is tested, but this PR does not add a focused Gmail setup utility regression test for the 800-code-unit surrogate-boundary formatter case.

Maintainer options:

  1. Decide the mitigation before merge
    Land the narrow formatter change after redacted real-behavior proof is posted, ideally with a focused Gmail setup utility regression test for the surrogate-boundary output case.
  2. Pause or close
    Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

  • [P1] No repair lane is appropriate because the code change is already narrow and the remaining blocker is contributor-owned real behavior proof.

Security
Cleared: The diff only swaps a string truncation helper in Gmail setup error-output formatting and introduces no concrete security or supply-chain concern.

Review details

Best possible solution:

Land the narrow formatter change after redacted real-behavior proof is posted, ideally with a focused Gmail setup utility regression test for the surrogate-boundary output case.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection gives a high-confidence path: current main slices stdout/stderr at 800 UTF-16 code units, so output with a surrogate pair crossing that boundary can produce an unpaired surrogate; I did not run the live Gmail setup flow.

Is this the best way to solve the issue?

Yes. Reusing the existing exported and tested truncateUtf16Safe helper at the formatter boundary is the narrow maintainable fix; the remaining gap is proof, not a different code shape.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 0bdd646fc21c.

Label changes

Label justifications:

  • P3: This is a small edge-case output-quality fix for Gmail setup error/debug text, not a broad setup blocker or runtime regression.
  • rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
  • status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: Missing: the PR body/comments have no after-fix Gmail setup terminal output, logs, or reproducible CLI transcript; the contributor should add redacted proof and update the PR body for re-review.
Evidence reviewed

PR surface:

Source +1. Total +1 across 1 file.

View PR surface stats
Area Files Added Removed Net
Source 1 2 1 +1
Tests 0 0 0 0
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 1 2 1 +1

What I checked:

  • Repository policy read: Root AGENTS.md was read fully; there is no scoped AGENTS.md under src/hooks, and the policy required source, history, proof, and best-fix review rather than a diff-only verdict. (AGENTS.md:1, 0bdd646fc21c)
  • Current main behavior: On current main, trimOutput truncates Gmail setup command output with trimmed.slice(0, MAX_OUTPUT_CHARS) before adding an ellipsis, so a surrogate pair split at the 800-code-unit boundary remains possible. (src/hooks/gmail-setup-utils.ts:19, 0bdd646fc21c)
  • Proposed patch: The PR changes only src/hooks/gmail-setup-utils.ts, importing truncateUtf16Safe and replacing the raw slice in trimOutput. (src/hooks/gmail-setup-utils.ts:28, 8f84ac9637c0)
  • Helper contract: truncateUtf16Safe clamps/floors the limit and delegates to sliceUtf16Safe, which avoids returning dangling surrogate halves at UTF-16 slice boundaries. (packages/normalization-core/src/utf16-slice.ts:44, 0bdd646fc21c)
  • Existing helper tests: Normalization-core tests cover truncateUtf16Safe, including truncation at a surrogate-pair boundary; the Gmail setup utility tests do not cover this formatter edge case directly. (packages/normalization-core/src/utf16-slice.test.ts:56, 0bdd646fc21c)
  • PR proof state: Live PR metadata and the existing ClawSweeper comment show no contributor Evidence section, proof comments, or linked real Gmail setup output/log proof for the current head. (8f84ac9637c0)

Likely related people:

  • steipete: Git history shows commit 2986447 introduced the Gmail setup command-output formatter and the raw slice truncation this PR changes. (role: introduced formatter behavior; confidence: high; commits: 2986447935c9; files: src/hooks/gmail-setup-utils.ts)
  • lsr911: Current-main blame for trimOutput and the normalization helper points to commit 1beea4b, which also reflects recent UTF-16-safe truncation work in adjacent debug-output code. (role: recent current-line contributor; confidence: medium; commits: 1beea4b87357; files: src/hooks/gmail-setup-utils.ts, packages/normalization-core/src/utf16-slice.ts)
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.
Review history (1 earlier review cycle)
  • reviewed 2026-07-09T11:31:22.099Z sha 8f84ac9 :: needs real behavior proof before merge. :: none

@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P3 Low-priority cleanup, docs, polish, ergonomics, or speculative work. labels Jul 9, 2026
@steipete

steipete commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

Thanks @zhangqueping. #102823 landed the same UTF-16-safe Gmail setup output cap in 5ef269c. The exact implementation is now on main, so this branch is fully superseded and I’m closing it.

@steipete steipete closed this Jul 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

P3 Low-priority cleanup, docs, polish, ergonomics, or speculative work. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. size: XS status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants