ipc_write_buffer opt is a no-op on 3008.x transport

Description

Starting with 3008.x the legacy salt.transport.ipc module was removed (commit 07a6a0788c4). The ipc_write_buffer option remained in the config schema for backwards compatibility, but is no longer wired to any code path — setting it in master.conf has no effect.

The equivalent per-stream max_write_buffer_size cap is now needed on:

• salt.transport.tcp.PubServer.handle_stream — event-pub subscribers
• salt.transport.tcp.PubServer._validate_ssl_and_add_client — SSL-delayed subscriber path
• salt.transport.tcp.SaltMessageServer.handle_stream — request/reply clients

Without the cap, a slow/blocked subscriber lets Tornado's outbound IOStream write buffer grow without bound. Under sustained event churn on the master this drove per-process RSS growth of hundreds of MB in a 4h validation rig.

Expected

Setting ipc_write_buffer: 1048576 (1 MB) in master.conf should cap each accepted Tornado stream's max_write_buffer_size at that value — matching the semantics of the legacy ipc module's per-connection cap.

Actual

The option is loaded into opts but never read by salt.transport.tcp. Streams keep Tornado's default (unlimited) write buffer.

Versions Report

3008.x (all releases since 3008.0), master.

Start in salt/transport/tcp.py and inspect PubServer.handle_stream, PubServer._validate_ssl_and_add_client, and SaltMessageServer.handle_stream, then trace how master.conf options reach opts. Verify that ipc_write_buffer sets each accepted stream's max_write_buffer_size for event-pub, SSL-delayed, and request/reply connections, including the 1 MB example behavior.