open https://gitlab.synchro.net/main/sbbs/-/issues/1129

A few sysops have been discussing this on IRC, and the issue appears to be reproducible. I’ve also tested it on both Linux and Windows with the same results. In short, while navigating around WebV4, there are intermittent long pauses that occur at times.

Example attached.{width=681 height=600}
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_8826

The web server log output at the time of those pauses would help determine the likely cause. e.g. if the web server has maxed out its client connections and is rejecting some of the (new) connections from the client, that could cause observable delays.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_8828

Currently set at 100 max clients and max con-conn set at 10. I'll enable received requests and transmitted responses for the log review.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_8829

updated max clients 500 max con-conn 50. enabled received requests and transmitted responses. was able to generate the long pause quickly with just a few clicks around the forum. attached web.log.

[web.log2026-04-19.log](/uploads/fd12482c62c02174f708d132b2c34d13/web.log2026-04-19.log)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_8830

What you attached is a web access log and not (generally) helpful for debugging. The actual web server log output that would be useful looks more like this:
```
4/19 09:43:40a 0952 HTTPS [34.205.45.217] Connection accepted on 71.95.196.34 port 443 from port 48492
4/19 09:43:40a 2864 HTTPS [34.196.237.236] Request 1: GET /files/Pier.Shareware/piergrfx/?view=%22GIFBLSTB.ZIP%22 HTTP/1.1
4/19 09:43:40a 2864 HTTPS [34.196.237.236] User-Agent: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Amazonbot/0.1; +https://developer.amazon.com/support/amazonbot) Chrome/119.0.6045.214 Safari/537.36
4/19 09:43:41a 0952 HTTPS [34.205.45.217] Request 1: GET /?page=002-files.xjs HTTP/1.1
4/19 09:43:41a 0952 HTTPS [34.205.45.217] User-Agent: Crawler test
4/19 09:43:41a 2864 HTTPS [34.196.237.236] Sending file: c:\sbbstemp\SBBS_SSJS.301028.2864.html (3808 bytes)
4/19 09:43:41a 2864 HTTPS [34.196.237.236] Sent file: c:\sbbstemp\SBBS_SSJS.301028.2864.html (3808 bytes)
4/19 09:43:41a 1920 HTTPS [34.205.45.217] Session thread terminated after 1 requests (5 clients and 13 threads remain, 6821 served, 29 concurrently)
4/19 09:43:42a 2864 HTTPS [34.196.237.236] Session thread terminated after 1 requests (4 clients and 11 threads remain, 6822 served, 29 concurrently)
4/19 09:43:45a 1896 HTTPS [74.7.241.38] Connection accepted on 71.95.196.34 port 443 from port 33918
4/19 09:43:45a 1896 HTTPS [74.7.241.38] Request 1: GET /?page=001-forum.ssjs&sub=syncprog&thread=54367 HTTP/1.1
4/19 09:43:45a 1896 HTTPS [74.7.241.38] User-Agent: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.3; +https://openai.com/gptbot)
```
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_8833

Attached. Note, it only takes a few clicks to reproduce. Jumping from one post to another for example.

[updated-log.txt](/uploads/0248757d193eeca752c3bb1886cdff14/updated-log.txt) --- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_8871

just did a test on the sync linux side with the same results. note, i don't have the webserver open to the internet so this was a lan test on port 80.

Apr 26 16:35:31 unix-bit synchronet[2937244]: web 0065 HTTP [192.168.1.12] User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36
Apr 26 16:35:31 unix-bit synchronet[2937244]: web 0065 HTTP [192.168.1.12] Request 3: GET /api/events.ssjs?subscribe=nodelist&subscribe=mail&subscribe=telegram HTTP/1.1
Apr 26 16:35:31 unix-bit synchronet[2937244]: web 0065 HTTP [192.168.1.12] User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36
Apr 26 16:35:32 unix-bit synchronet[2937244]: web 0046 HTTP [192.168.1.12] Session thread terminated after 5 requests (6 clients and 14 threads remain, 2 served, 7 concurrently)
Apr 26 16:35:34 unix-bit synchronet[2937244]: web 0050 HTTP [192.168.1.12] Session thread terminated after 4 requests (5 clients and 12 threads remain, 3 served, 7 concurrently)
Apr 26 16:35:34 unix-bit synchronet[2937244]: web 0052 HTTP [192.168.1.12] Session thread terminated after 5 requests (4 clients and 10 threads remain, 4 served, 7 concurrently)
Apr 26 16:35:35 unix-bit synchronet[2937244]: web 0051 HTTP [192.168.1.12] Session thread terminated after 6 requests (3 clients and 8 threads remain, 5 served, 7 concurrently)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_8872

That log output isn't useful. The full log session should start from the connection/request lines. Enabling debug-level logging would be even more helpful. Also, when pasting logs here, enclose in a code block:
```
like this
```
that said, it sounds like something that's likely going to need more instrumentation (trace-like log messages) and reproduction by someone to debug. So I wouldn't bother worrying about capturing and attaching more log snippets to this issue right now.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

close https://gitlab.synchro.net/main/sbbs/-/issues/1129
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_9258

The problem went away?
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_9262

There have been a few recent updates to the Synchronet web server, but not webv4 (echicken's dynamic web UI), that I recall.

So no changes made directly pertaining to this issue, yet.
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1129#note_9470

Working with my Claude on this. This issue seems fixed on myside:

# Issue #1129 — Long Pauses When Clicking Around Sync WebV4

## Summary

Two bugs identified and patched. Both are required for a complete fix. Tested on X-Bit BBS (Synchronet v3.22a, Windows 10) with 200+ message areas across FidoNet, DoveNET, fsxNet, tqwNet, and Zer0net.

---

## Bug 1 — `listSubs()` opens MsgBase for every sub unnecessarily (server-side)

**File:** `webv4/lib/forum.js`

### Root Cause

`listSubs()` is called at page render time every time a user clicks a group (e.g. FidoNet) to view its list of sub-boards. It opens a `MsgBase` instance for **every sub in the group**, even though the two fields that actually require an open MsgBase (`unread` and `newest`) are both **commented out**:

```javascript
// unread: is_user() ? getSubUnreadCount(mb) : null,
// newest: getNewestMessageInSub(mb),
```

On a system with 141 FidoNet echos, this means 141 `MsgBase.open()` + `MsgBase.close()` calls on every single click of the FidoNet group link — purely wasted I/O with no effect on the rendered output. This was enough to cause the page render thread to stall for several seconds, which manifests as the browser spinner when navigating back and forth rapidly.

### Fix

Remove the MsgBase open/close entirely from `listSubs()` since neither field requiring