Beagle SCM

STATUS-003 HIGH: 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).