Beagle SCM

STATUS-003: full-repo be / be post SNOROOM on a large sub aborts the parent commit

Bare be (full-repo status) and be post recurse into the html submodule (483 files on disk, 481 tracked); AFTER html's clean 481 ok summary a cumulative status/HUNK buffer overflows → Error: SNOROOM → Error: BEDOGEXIT, and be post then ABORTS the parent commit ("sub recursion failed — worst=BEDOGEXIT"). Crucially be status:html ALONE is fine (rc=0, 481 ok), so the overflow is in the AGGREGATE recursion, not html's own scan. A clean/unchanged big sub wedges all landing. Method: Issues.

Input

Context

• Repro (journal root, with the html sub present): bare be → status:html / ?91ae5b53… 481 ok then Error: SNOROOM / Error: BEDOGEXIT, then it continues to status:be/test, … — so SNOROOM fires at the html→parent aggregate boundary, not fatally to the scan.
• be post '<msg>' → on the html sub: Error: SNOROOM / Error: BEDOGEXIT / be: post: aborting parent commit — sub recursion failed (worst=BEDOGEXIT) — the whole commit aborts even though html is UNCHANGED (nothing to stage).
• ISOLATION: be status:html standalone → rc=0, 481 ok, NO SNOROOM (verified). So html's per-sub status fits; the OVERFLOW is the parent accumulating sub results across many subs (parent 31 + be/test 17 + beagle 6 + html 481 + …).
• SNOROOM (abc/01.h:124) is returned by an abc slice feed (abc/Sx.h/BUF.h) when the caller's into slice is too small — a FIXED buffer, not grow-on-room.
• Candidate buffers in the dispatcher status/post recursion: beagle/BE.cli.c:237 a_carve(u8, cbuf, 1UL<<20) (1 MiB) and :322 a_carve(u8, sbuf, 64UL<<10) (64 KiB) — the 64 KiB one is the likely cumulative overflow once a 481-row sub piles onto the aggregate.
• ALSO affects be/ STANDALONE: cd be && be status → SNOROOM/BEDOGEXIT (no ok count) — be/'s own tracked set overflows the same buffer. So be/ can't be statused or be post-ed standalone EITHER, and it drops from the parent submodule list (BE-009). No be post workaround exists for be/ until fixed.
• Impact: BLOCKS be post for any tree containing a large sub AND blocks landing the be/ code-review fixes (JS-065..091) entirely; surfaced this session.

Goals

• Full-repo be and be post handle a large sub (≥481 entries / large cumulative output) WITHOUT SNOROOM; an unchanged/clean sub NEVER aborts the parent commit.
• A repro fixture (a sub with ≥N files that overflows the aggregate today) that passes after the fix; full beagle ctest stays green.

Constraints

• Native sniff/keeper/dog only. Prefer grow-on-NOROOM (the JS-055 _grow-on- SNOROOM pattern / a_carve+retry) over a bigger fixed cap — a fixed bump just moves the cliff. Don't regress small-repo status/post output bytes.

WIP

Design decisions

• Locate the overflowing carve/feed (start at BE.cli.c:322 sbuf 64 KiB and the HUNK-table sink the sub-recursion writes into); size it to the cumulative row/ byte count or grow it on SNOROOM and retry, mirroring git.pack's NOROOM grow.
• Decouple a sub's recursion failure from the parent commit where the sub is a no-op (an UNCHANGED sub must not contribute a fatal BEDOGEXIT).

TODOs

• Repro-first: dog/test/ULOG.c::T_open_over_1024_rows (a >1024-row log that overflowed the fixed scratch index; RED pre-fix).
• Find + right-size the buffer: dog/ULOG.c ulog_idx_scan_cap sizes the scratch index to content (log_size/16 + 1024, capped at the sidecar ceiling) — the BE.cli.c carves were a red herring.
• Verify: bare be over the journal tree rc=0 (no SNOROOM), cd be && be status rc=0; beagle 464/464 + be 65/65 green; small-repo output unchanged.

Blockers and bummers

• Two failure modes are tangled: the SNOROOM (buffer) and the PUTNONE/NONE spam (PUT-003) both appear in the same be post recursion — fix independently.

Outcome

• LANDED dog be89684d / beagle pin e5071f32 "ULOG-003: ensure ulog index has the capacity" (the commit rode the ULOG-003 label; dog/ULOG.c's ulog_idx_scan_cap comment cites STATUS-003). Audit 2026-07-07: sizing + repro test verified in-tree. CLOSED.
• FIXED (working tree, pending land): dog/ULOG.c — the fixed 1024-row scratch index in ULOGOpenRO/ULOGOpenBooked/ULOGOpenIdx now sizes to content (log_size/16 + 1024); be/.be (1030 wtlog rows) overflowed it. The dispatcher carve (BE.cli.c:237/:322) was a red herring (diff:-only). Repro dog/test/ULOG.c::T_open_over_1024_rows. Verified: bare be over the journal tree rc=0 (6 status: blocks, no SNOROOM); cd be && be status rc=0; beagle 464/464 + be 65/65. The BEDOGEXIT-decouple WIP item is moot (SNOROOM gone).