bug: large chat context can reset agent websocket instead of returning a clear context-too-large error

[alexma233]

Summary

When a bot conversation has a very large context window, sending a message may fail with:

• gateway ws write start: write tcp ...: write: connection reset by peer

Reducing the bot's context time from a larger value to 400min makes the problem disappear, so this appears to be related to oversized websocket startup payloads.

Environment

• Project: Memoh
• Runtime: dev docker environment
• Services involved:
  • server
  • agent gateway
• Date observed: 2026-03-15

Steps to Reproduce

1. Use a bot with a long conversation history
2. Set a large activeContextTime / context time
3. Send a new message through the bot
4. Observe intermittent failure before streaming starts

Actual Behavior

The request fails with a websocket reset error from server -> agent gateway:

time=2026-03-15T15:46:08.841+08:00 level=INFO msg="gateway ws connect" service=conversation_resolver url=ws://agent:8081/chat/ws bot_id=75ae65a9-927a-4f59-b271-1c8f7bb76545
time=2026-03-15T15:46:09.081+08:00 level=ERROR msg="ws stream error" handler=local_channel error="gateway ws write start: write tcp 172.21.0.3:54152->172.21.0.4:8081: write: connection reset by peer"

This happens while writing the initial start payload to /chat/ws.

Expected Behavior

If the context is too large, the system should:

• either trim/compress history before sending
• or reject the request with a clear, user-facing error such as context too large
• but not reset the websocket connection with a low-level transport error

Observations

• Lowering context time to 400min makes the issue disappear
• This strongly suggests the initial websocket payload becomes too large when history is long
• The current behavior makes it look like infra/network instability, while the root cause is likely payload size / missing guardrails

Suspected Cause

The websocket start message appears to include the full request payload, including long message history and tools, in a single frame.

Relevant code paths:

• internal/conversation/flow/resolver.go:733
• apps/agent/src/modules/chat.ts:125

The agent gateway websocket server does not appear to explicitly configure a larger maxPayloadLength, and there is no graceful handling for oversized startup payloads.

Suggested Fixes

• Add request size / payload size validation before sending websocket start
• Return a clear error when the context payload is too large
• Consider trimming or summarizing history before websocket handoff
• Optionally configure websocket maxPayloadLength explicitly on the agent gateway
• Add logging for serialized startup payload size to make diagnosis easier