chat: recover from V8 max-string-length when persisting session state

[roblourens]

Fixes #308843.

Problem

JSON.stringify of the full chat session state could throw RangeError: Invalid string length during compaction, losing the entire chat session. The session-store mutation log compacts every 1024 entries by writing a single Initial entry containing the full serialized state; with multiple large tool result values stored under IChatAgentResult.metadata.toolCallResults (notably Copilot's read_page tool, whose results can be ~60 MiB each), the combined JSON exceeded V8's ~512 MiB max string length.

Field forensics in the issue showed one tool result alone at ~61 MiB and a JSONL log file at ~640 MiB with one line at ~503 MiB before serialization eventually failed.

Fix

Wrap the three JSON.stringify(entry) call sites in ObjectMutationLog with stringifyEntryWithFallback, which:

• Common path: a single JSON.stringify — zero overhead.
• Failure path: on RangeError, retry with a truncating replacer that caps individual strings at 1 MiB and the total tracked size at 100 MiB. Oversized values are replaced with a clear marker (e.g. [VS Code: value truncated for persistence; original 314572800 chars]).
• Non-RangeError exceptions (circular refs, etc.) propagate unchanged.

The fix lives at the engine level rather than in the chat schema, so:

• The common path doesn't pay any pre-walk cost.
• It's generic — defends against any future schema field that could grow unbounded, not just result.
• The schema and live ChatModel are unchanged.

Copilot's prompt path already replaces tool results > 8 KiB with on-disk file references when building prompts, so a truncated persisted copy has no functional impact on conversation resume — only the unbounded "for the record" copy is affected.

Notes for reviewers

• Cap sizing rationale: 1 MiB per string is dramatically larger than any legitimate single string in chat state; 100 MiB total leaves ample headroom under V8's ~512 MiB limit even on extreme sessions.
• Tests use a toJSON() hook to trigger a real RangeError mid-stringify without requiring 300+ MiB allocations — fast (<10 ms) and exercises the actual catch+retry path. I also verified end-to-end against an actual V8 RangeError locally (allocating a 300 MiB string referenced twice in an object) and confirmed full recovery through createInitial + read round-trip.
• Truncation only takes effect on actual failure; sessions in normal use are byte-for-byte identical to before.

(Written by Copilot)

[Copilot]

Pull request overview

This PR hardens chat session persistence against V8’s max string length limit by adding a fallback serialization path in the chat session mutation log, preventing entire sessions from being lost when a compaction write would otherwise throw RangeError: Invalid string length.

Changes:

• Added stringifyEntryWithFallback to retry JSON.stringify with a truncating replacer after RangeError.
• Introduced a stateful truncating replacer that caps individual strings and enforces an overall serialization budget on retry.
• Added unit tests covering truncation behavior and the RangeError retry path.

Show a summary per file

File	Description
src/vs/workbench/contrib/chat/common/model/objectMutationLog.ts	Wraps log entry serialization with a RangeError recovery path and adds truncation helpers/constants.
src/vs/workbench/contrib/chat/test/common/model/chatSessionOperationLog.test.ts	Adds tests validating truncation and fallback stringify behavior.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 2