bash read -t timeout status is 1 on bash 3.2 (macOS) but >128 on bash 4+; a stdin relay in a pipeline delays error reporting

A stdin relay that tells a timeout from EOF by status (read -r -t 1 part fails; status > 128 is a timeout, anything else is EOF) works on Linux bash 4/5, where a timeout gives 142. On macOS /bin/bash 3.2 a read -t timeout returns 1 (check: read -t 1 x < <(sleep 3); echo $?). So the relay takes every 1 s of silence as EOF. A local test that only checks the session ends before an N-second idle limit then passes for the wrong reason, so also assert a lower bound, or tell timeout from EOF by elapsed time (SECONDS).

Second trap: in relay | consumer | tee log | grep, the script waits for every member of the pipeline. If the consumer exits on its own (start failure, crash), the relay keeps looping in read -t until stdin ends, a write fails, or the idle limit passes. The script's error-reporting code after the pipeline then runs late, and the client sees a request timeout instead of the real error. Fix: run the consumer in the background reading a fifo, and have the relay check kill -0 on its PID every tick (or use wait -n).