https://gitlab.synchro.net/main/sbbs/-/issues/1148#note_9067

Confirmed non-reproduction on Linux against current master.

Ran the repro script verbatim from `/sbbs/jsexec`:

```
$ jsexec /tmp/issue1148/repro1148.js
call 1: rc=200 body.len=946
call 2: rc=200 body.len=946
call 3: rc=200 body.len=946
```

Also extended to 5 iterations × 3 hosts (gitlab.synchro.net, httpbin.org, www.google.com) — all 15 HTTPS GETs returned rc=200 with sane body sizes, no `Unable to read status` thrown. Matches Deuce's earlier non-repro.

So the failure mode appears Windows-specific. Leaving the issue closed; if it resurfaces on Windows I'll reopen with a cryptlib log capture (`data/error.log` + per-day TS log) from a failing run, plus a test against a different `cl32.dll` build to rule the bundled cryptlib in or out.

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

https://gitlab.synchro.net/main/sbbs/-/issues/1148#note_9068

Two corrections to my prior follow-up:

**Log-file references were wrong.** The closing line suggested capturing `data/error.log` + the per-day Terminal Server log if it resurfaces on Windows. Neither captures a `jsexec` failure — `data/error.log` is the server-side `errormsg()`/`LOG_ERR` sink, and `data/logs/<date>.log` records Terminal Server *sessions*. `jsexec` is standalone and writes only to its own stdout/stderr (or `-L <file>` / `-e <file>`). The actually useful diagnostic here would be the cryptlib status code/string from the failing socket op, surfaced through `js_socket.cpp` — which currently propagates only as a bare `"Unable to read status"` JS exception with no underlying error context. A small `lprintf` or exception-message enrichment that includes the cryptlib reason would make this kind of bug far easier to triage next time.

**"If it resurfaces on Windows" understates the state.** It hasn't gone away. It reproduces 100% on Windows against current master in both Release (`master/edf752429`) and Debug (`master/0db1c34fc`) builds with the verbatim repro from this issue. The Linux non-reproduction localizes the bug; it doesn't fix it. Leaving the issue closed since the original report misdiagnosed the cause, but the underlying Windows failure is reliably present, not a "watch for it" item.

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

https://gitlab.synchro.net/main/sbbs/-/issues/1148#note_10069

Second real-world hit, different module — `letsyncrypt.js --force` Ran into this same error via `letsyncrypt.js --force`, which seems like a textbook fit for the same-host-repeat-request pattern described above: an ACME renewal against `acme-v02.api.letsencrypt.org` needs several sequential HTTPS calls to that one host (directory, order, challenge, finalize), so I suspect this is hitting the same TLS-session-cache issue rather than a bug in `letsyncrypt.js` itself. Environment Synchronet 3.21e, Windows 11 Pro, Version 25H2 (OS Build 26200.8973) `letsyncrypt.ini`: `TOSAgreed=true`, existing registered ACME account (`\[key\_id]` present, live account on `acme-v02.api.letsencrypt.org`), pre-existing `letsyncrypt.key` ACME HTTP-01 challenge webroot confirmed reachable (nginx passthrough for `/.well-known/acme-challenge/` added ahead of the existing redirect, verified with `nginx -t` and a full service restart) Repro `jsexec letsyncrypt.js --force`, run 3 separate times, all 3 failed identically:

```
!JavaScript C:\\sbbs\\exec\\load\\http.js line 147: Error: Unable to read status
exit\_code 1
```

Run times varied (8.25s, 1.44s, 1.43s) — consistent with real work/multiple round-trips happening before hitting the repeat-request wall, not an instant reject. For reference, a plain `jsexec letsyncrypt.js` (no `--force`) exits cleanly (errorlevel 0) in \~0.2s with none of the intermediate progress output seen in other successful runs — almost certainly a no-op (no renewal due), not evidence the underlying path works. Happy to provide full logs or `letsyncrypt.ini` (redacted) if useful for narrowing this down further.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)