perf: replace O(n²) splice with O(n) filter in filterHeartbeatMessages

[yuanrengu]

Summary

Replace two levels of splice() calls in filterHeartbeatMessages with a filter-then-rebuild approach, reducing time complexity from O(n²) to O(n).

The function filters heartbeat tool calls from the messages array before LLM input. Previously it used messages.splice(i, 1) in the outer loop and content.splice(j, 1) in the inner loop — both O(n) per call due to element shifting.

Changes

• Add setMessageContentLocal(msg, newContent) helper for consistent content reassignment across msg.type === "message" and normal message shapes
• Outer loop: replace reverse iteration + splice(i, 1) → forward iteration into kept[] array, skipping removed messages via continue
• Inner loop: replace reverse iteration + splice(j, 1) → content.filter(block => !isHeartbeatToolUseBlock(block))
• Rebuild messages array in-place from kept list at the end

Behavior

No functional change — same heartbeat detection, same count semantics, same in-place mutation contract:

Aspect	Before	After
Heartbeat ID collection	O(n) scan	O(n) scan (same)
Message removal	splice(i, 1), O(n) each	skip via continue, O(1)
Content block removal	splice(j, 1), O(n) each	filter, O(n) total
Overall time	O(n²) worst-case	O(n)
Removal count	1 per message	1 per message (same)

Test plan

• npx tsdown builds successfully
• Heartbeat ID collection unchanged
• Same messages are removed (tool/toolResult by tcId, assistant by content blocks)
• Content block filtering preserves non-heartbeat blocks
• In-place mutation contract preserved (callers receive mutated array)

[Maxwell-Code07]

Hi @yuanrengu, thanks for the PR! 👍

The splice → filter optimization in filterHeartbeatMessages is an interesting direction. We'll review the implementation details and get back to you shortly.

Thanks for the contribution! 🙏