https://gitlab.synchro.net/main/sbbs/-/issues/1156#note_9344

A follow-on regression from the same root cause surfaced after this was closed.

cfa6fe9e1 (*bolt-11-banner*) exempted **static** services (IRC daemon, MRC connector) from the `js_OperationCallback` disconnect check added in ead5ccf16 (*song-11-earn*), but **per-connection** service scripts were still aborted ~10 callbacks after the client disconnects.

BinkIT, run as the inbound binkp service, intentionally keeps working after the peer disconnects — it finishes the batch, updates `binkstats.ini`, and as its last act touches the `FIDOIN`/`BINKOUT` event semaphores. The disconnect check aborted it mid-cleanup (`!JavaScript warning .../binkit.js line 1268: Disconnected`), so the semaphores were never touched and **outbound FTN mail to downlinks silently piled up** (reported by Gamgee / Palantir BBS).

Fixed in fc82a6d91 (*wooden-11-choices*): the client-disconnect abort is decoupled from `auto_terminate` into a new `js.terminate_on_disconnect` callback property — default on for the Terminal, Web, and Services servers, while `auto_terminate` again governs only server shutdown/recycle. `binkit.js` opts out with `js.terminate_on_disconnect=false`; stock scripts that previously set `js.auto_terminate=false` to ride out a disconnect (`dorkit.js`, `irc.js`, `lockfile.js`) now clear the new flag in lockstep.

Pull + rebuild and the FIDOIN/BINKOUT events will fire again after inbound polls.

— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)