fix(publish): cap concurrent WebSocket connections with semaphore

[mw2000]

Builds on the handshake timeout and spawned-handshake improvements from #1252.

Summary

• Adds a tokio::sync::Semaphore to bound the number of concurrent WebSocket connections (handshaking + active) to a configurable limit (default 8192)
• Adds on_connection_rejected to the PublisherMetrics trait so rejected connections are observable
• Adds Listener::with_max_connections builder method to override the default limit

Problem

There is no bound on the number of concurrently spawned tasks in the WebSocket listener. Under heavy connection pressure, each new TCP connection spawns a task that lives for up to HANDSHAKE_TIMEOUT (10s) even if it never completes the upgrade. At sustained rates this can exhaust memory and task-scheduler resources before timeouts reclaim anything.

Fix

Guard tokio::spawn with an Arc<Semaphore> using try_acquire_owned. The permit is held for the entire lifetime of the spawned task (handshake + broadcast), so it is released when the client disconnects. Connections beyond the limit are dropped immediately with a debug log and a metric callback.

Testing

All 25 tests pass (cargo test -p base-builder-publish), including a new listener_rejects_connections_beyond_limit test that verifies the semaphore rejects excess connections.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
base	Ignored	Preview	Apr 8, 2026 0:53am

[github-actions]

nit: with_max_connections(0) will create a Semaphore::new(0) that rejects every connection unconditionally. Consider validating the input or using NonZeroUsize:

Suggested change

	self.max_connections = max_connections;
	pub const fn with_max_connections(mut self, max_connections: NonZeroUsize) -> Self {
	self.max_connections = max_connections.get();
	self

Alternatively, a runtime assert!(max_connections > 0) or saturating to 1 would also work. Not a blocker, but a zero-capacity listener is almost certainly a misconfiguration.

[mw2000]

we're using this for the unit test

[github-actions]

Review Summary

Solid PR that addresses a real DoS vector. The semaphore-based approach is the right tool for the job — try_acquire_owned is non-blocking and the owned permit naturally ties the connection lifetime to the semaphore slot.

What looks good

• Semaphore placement: Acquiring before tokio::spawn means the limit covers both handshaking and active connections, which is the correct granularity.
• debug! log level: Previous review flagged warn! as a secondary DoS vector under flood conditions — addressed correctly.
• Default body on on_connection_rejected: Since all PublisherMetrics impls are internal to this crate, the default no-op is fine and avoids a breaking change to the trait.
• Test coverage: The new test exercises the reject path with with_max_connections(1) and verifies the metric counter.

Finding

• with_max_connections(0) is silently accepted — creates a listener that rejects 100% of connections. Consider using NonZeroUsize or adding a runtime assertion. (minor, posted inline)

[mw2000]

Upon some further review, we will hold off/close this PR

The main reason is the number of connections on mainnet are too low (~30) since the builder mostly sits behind websocket proxy.