websocket disconnections

[rgarcia]

• changed run-unikernel scripts to match resources used in prod
• added an env var flag LOG_CDP_MESSAGES that will log a condensed form of each CDP message
• removed the heartbeat ping. Turns out browser use sometimes asks a /lot/ of the CDP connection when it first begins. It pulls the accessibilty tree plus full document which can be many MBs. Was seeing this ping time out during this initial startup, causing us to close the connection.
• adjusted websocket dialer and connection to be very lenient
• changed the uk-check-stats script to compute a real cpu % and a KB/s network rate

todo:

• test with API in the middle
• test keeping the ping but not killing the connection if it times out

---

TL;DR

Fixes websocket disconnections by removing the aggressive heartbeat ping that was causing timeouts during heavy initial browser load.

Why we made these changes

During initial startup, the browser's Chrome DevTools Protocol (CDP) connection can be saturated with large amounts of data (e.g., accessibility tree, full document), which can be many megabytes. The existing heartbeat ping was timing out during this heavy load, causing us to prematurely close valid connections. These changes make the connection more lenient and robust, especially during startup.

What changed?

• Websocket Stability: Removed the custom heartbeat ping logic in server/lib/devtoolsproxy/proxy.go to prevent timeouts. Adjusted websocket dialer settings to be more lenient with larger buffers, compression, and no deadlines.
• Debugging & Observability:
  • Added a LOG_CDP_MESSAGES environment variable to log a condensed form of each CDP message for easier debugging.
  • Enhanced the shared/uk-check-stats.sh script to compute and display a real CPU percentage and network throughput in KB/s.
• Configuration:
  • Updated run-unikernel.sh scripts for both chromium-headful (4 vCPUs) and chromium-headless (1 vCPU) to align resource usage with production environments.

^{Description generated by Mesa. Update settings}

[mesa-dot-dev]

Performed full review of 330685e...cd0123c

Tip

⚡ Quick Actions

This review was generated by Mesa.

Actions:

• Configure your agents

Slash Commands:

• /review - Request a full code review
• /review latest - Review only changes since the last review
• /describe - Generate PR description. This will update the PR body or issue comment depending on your configuration
• /help - Get help with Mesa commands and configuration options

^{9 files reviewed | 3 comments | Review on Mesa | Edit Reviewer Settings}

[mesa-dot-dev]

There's a conflicting vcpus configuration. Line 18 sets --vcpus 1 but line 24 sets --vcpus 2. The last one will override the first, so this instance will actually use 2 CPUs, not 1 as intended by the first setting.
_{Agent: 🤖 General}

[mesa-dot-dev]

Setting ReadLimit to 100MB could potentially expose the system to memory exhaustion attacks if a malicious client sends very large messages. Consider if this limit is truly necessary or if a more conservative limit (e.g., 10MB) would still handle legitimate CDP use cases.
_{Agent: 🤖 General}

[mesa-dot-dev]

The regex-based JSON parsing in logCDPMessage is fragile and could fail with escaped quotes, nested objects, or malformed JSON. Consider using json.Unmarshal with a simple struct that captures the fields you need, which would be more robust and performant.
_{Agent: 🤖 General}

[Sayan-]

Overall lgtm! A few questions I had prior to merging:

1. How'd we decide the buffer sizes? What's the behavior when those buffers get full?
2. Any concerns with additional resource usage enabling compression? Any other changes we need to make to enable the compression? I'd expect it to just work with chromium but unclear from our intermediate hops. From the docs I see:

This function is a noop if compression was not negotiated with the peer.

[rgarcia]

1. From my reading it seems like the behavior when those buffers get filled is network lag--basically the buffer gets filled and then the connection stops reading data. Making them big hopefully accommodates big spikes in network activity with less lag
2. I think the overhead is pretty minimal of compression but yes it depends on the client asking for it (in our case, the API). I mainly enabled it to minimize stress on the network. I was not seeing CPU limit (4) getting hit in my observations of uk-check-stats output

[Sayan-]

== to both thanks for confirming! I haven't read the gorilla implementation deeply enough to confirm whether it would drop packets / eventually terminate the connection when the buffer gets filled. Cross checking their current code and we're a 16x bump from the default, which I think we can continue to bump without too many worries (https://github.com/gorilla/websocket/blob/main/conn.go#L36-L37)