• docs/v322_new.md webv4/lib/events/forum.js webv4/lib/forum.js

    From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wednesday, November 11, 2026 22:22:46
    https://gitlab.synchro.net/main/sbbs/-/commit/dbc2439f2dc687e41c8eaf66
    Modified Files:
    docs/v322_new.md webv4/lib/events/forum.js webv4/lib/forum.js
    Log Message:
    webv4: count unread forum messages from the index, not a lookup per number

    getSubUnreadCount() called MsgBase.get_msg_header() for every message
    number from the user's scan pointer to last_msg. Sparse numbering makes
    that far more lookups than messages, and lib/events/forum.js re-ran it
    for every sub, every refresh_interval (60 s), for each logged-in viewer
    of the forum's group or sub list.

    Symptom: on vert.synchro.net, with the message bases on an SMB share, get-group-unread-counts for a user with 28,900 unread messages took
    355 s, so the 60 s scan ran back to back for as long as the page was
    open. It now takes 9 s; get-sub-unread-counts for one 20-sub group
    went from 69 s to 3 s, with identical output.

    Read the index once with MsgBase.get_index() and walk back from its end
    to the scan pointer. A header is read only when counting messages to
    the user and the index's name CRC matches. A sub whose last_msg,
    total_msgs, scan pointer and scan config are unchanged since it was
    last counted by the same script returns the previous count, so the
    event stream stops recounting idle subs. A message deleted without any
    other change to its sub is not noticed until then.

    In lib/events/forum.js, set last_run after the scan rather than before (fac16e6927, 2019-07-19), so a scan slower than refresh_interval is not followed immediately by another, and don't rebuild a sub's threads when
    its message base and the scan pointer are unchanged.

    Two fixes in getMessageThreads():

    - With forum_no_spam set and max_messages=0 it threw a ReferenceError:
    is_spam() was passed an undefined variable (08a2638b8d, 2020-01-08).
    - With max_messages > 0 it read the numbers last_msg - max through
    last_msg, which hold fewer than max messages when numbering is
    sparse, so threads were dropped (61cb4097fb, 2016-12-25). Take the
    newest max messages from the index.

    The per-number unread loop has been there since webv4 was imported
    into this repository in 3f16cac564 (2020-09-07).

    Part of #1339. Thread views still read every header in the sub.

    Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

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