https://gitlab.synchro.net/main/sbbs/-/commit/666ff71ceef9557cbb62d0a5
Modified Files:
exec/tests/msgbase/get_all_msg_headers.js src/sbbs3/js_msgbase.cpp
Log Message:
js_msgbase: fully fix get_all_msg_headers() *_NULL fields on real mailbases

Commit ca448cb8b eagerly JS_DefineProperty("number") per header to force a SpiderMonkey shape transition, fixing get_all_msg_headers() header objects returning undefined on first access of a LAZY_STRING_TRUNCSP_NULL field (to_ext, from_ext, replyto, to_list, cc_list, summary, tags, from_org, ...). That masked the bug for tiny/uniform message bases (and the single-message regression test), but NOT for real mailboxes: the resolve hook still leaves a *_NULL field undefined whenever its value is NULL, which corrupts the 1.8.5 property cache for the shared header shape, so every subsequent same-shape header then reads undefined on first access of that field. On a live ~14.4k- message mail base this bit ~98% of headers once the first NULL-to_ext message appeared (cold to_ext==1 count: 0; correct count after priming: ~9150).

Fix: eagerly RESOLVE each header's data fields at construction in js_get_all_msg_headers (js_get_msg_header_resolve with JSID_VOID) instead of just defining 'number'. Non-NULL fields become own properties up front, so callers iterating bulk-fetched headers never trigger the GET-path lazy resolve (nor the property-cache fast-path that mis-serves undefined). A new privatemsg_t.defer_listing flag skips the expensive field_list[]/can_read branches during this eager pass (they remain lazily resolved on first access), and p->enumerated is left unset so a later enumeration still builds them. Fetch cost is unchanged (dominated by smb_getmsghdr, not field population).

Extend exec/tests/msgbase/get_all_msg_headers.js with a multi-message, mixed-NULL, shape-diverse bulk scenario that reads *_NULL fields as the first access. Note: the real-mailbox property-cache corruption could not be reproduced with synthetic save_msg()'d messages, so the test is a behavioral guard validated against a real base, not a standalone reproducer.

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

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