https://gitlab.synchro.net/main/sbbs/-/commit/fc82a6d911697e86dad4b9cc
Modified Files:
docs/v322_new.md exec/binkit.js irc.js exec/load/dorkit.js lockfile.js src/sbbs3/exec.cpp js_internal.cpp main.cpp sbbs.h services.cpp websrvr.cpp
Log Message:
services/web/terminal: decouple JS client-disconnect termination from auto_terminate

ead5ccf16 (song-11-earn) "Detect disconnection in JavaScript callback" overloaded the js_callback_t.auto_terminate flag - historically just
"abort on server shutdown/recycle" - to also abort a script ~10 operation-callbacks after its client socket disconnects. cfa6fe9e1 (bolt-11-banner) exempted static services (IRC daemon, MRC connector),
but per-connection service scripts were left exposed.

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, so those semaphores were never
touched and outbound FTN mail to downlinks silently piled up.

Decouple the two concerns with a new js_callback_t.terminate_on_disconnect control (exposed as the js.terminate_on_disconnect property), distinct
from auto_terminate (which again governs only shutdown/recycle, via js_CommonOperationCallback). All three client-connected servers now gate
their disconnect abort on terminate_on_disconnect and share a single JS_DISCONNECT_TERMINATE_COUNT (10) constant, replacing three literal 10s (including the long-standing terminal check in exec.cpp). Default true in
the Terminal, Web, and Services servers; binkit.js opts out with js.terminate_on_disconnect=false. js_EvalOnExit suspends it alongside auto_terminate so on-exit cleanup can't be cut short.

Stock scripts that previously set js.auto_terminate=false to ride out a
client disconnect now set terminate_on_disconnect in lockstep: dorkit.js (self-manages carrier loss), irc.js, and lockfile.js (UnlockAll - avoids
stale locks if killed mid-unlock, which also closes the same exposure for per-connection services).

Re #1156.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net