Environment
- SIA v1.7.8 (Omarchy plugin khephri.sia), Arch Linux
- Host: 1128 installed pacman packages
What happens
sia backup now fails during capsule freeze:
ValueError: capsule source directory exceeds its entry bound
Traceback path: siacapsule.freeze -> _copy_tree raising at siacapsule.py:721-723.
Root cause
~/.local/share/sia/corpus/packages/ accumulates one entity page per package ever seen in /var/log/pacman.log (via sense_pacman -> ensure_event_entities). On this host that directory holds 1130 files.
_CAPSULE_DIRECTORY_ENTRY_LIMIT (siacapsule.py:104) is set to sialib.MAX_SOURCE_SCAN_ENTRIES, which is MAX_SOURCE_TAIL_RECORDS = 1024 — a bound meant for tailing bounded evidence sources, reused as a capsule copy bound. So the freeze can never succeed on any machine with more than 1024 packages:
_CAPSULE_DIRECTORY_ENTRY_LIMIT = sialib.MAX_SOURCE_SCAN_ENTRIES # 1024
A full Arch desktop routinely exceeds this; the failure is structural, not data corruption. The refusal is honest (nothing is silently skipped) but it makes Continuity permanently unconfigured-but-broken on such hosts — the cockpit shows a failed backup with no operator remedy short of hand-deleting corpus pages, which the corpus/ledger invariants arguably forbid.
Possible directions (your call)
- Raise or decouple the capsule entry/record bounds from the source-scan constants (the capsule already signs every entry; the bound's job is bounding, not 1024 specifically).
- Shard
corpus/packages/ like event pages are sharded, keeping fan-out under the bound.
- Consolidate per-package entity pages (e.g. one page per package only while installed, or a package index page), reducing fan-out at the source.
- Emit a specific operator-facing error ("too many package pages; X > bound Y") instead of the generic failed-without-detail status, so the cockpit can explain the state.
Option 1 alone changes a safety constant; options 2/3 are structural. Happy to test any candidate on this host since it's a natural >1024-package reproducer.
Workaround considered locally
None clean: the runtime is digest-pinned by managed-install/runtime, so patching siacapsule.py in place would be refused by the tamper-evidence model — correctly, I'd add. We've left Continuity in the failed state pending an upstream fix.
Environment
What happens
sia backup nowfails during capsule freeze:Traceback path:
siacapsule.freeze -> _copy_treeraising atsiacapsule.py:721-723.Root cause
~/.local/share/sia/corpus/packages/accumulates one entity page per package ever seen in/var/log/pacman.log(viasense_pacman->ensure_event_entities). On this host that directory holds 1130 files._CAPSULE_DIRECTORY_ENTRY_LIMIT(siacapsule.py:104) is set tosialib.MAX_SOURCE_SCAN_ENTRIES, which isMAX_SOURCE_TAIL_RECORDS = 1024— a bound meant for tailing bounded evidence sources, reused as a capsule copy bound. So the freeze can never succeed on any machine with more than 1024 packages:A full Arch desktop routinely exceeds this; the failure is structural, not data corruption. The refusal is honest (nothing is silently skipped) but it makes Continuity permanently unconfigured-but-broken on such hosts — the cockpit shows a failed backup with no operator remedy short of hand-deleting corpus pages, which the corpus/ledger invariants arguably forbid.
Possible directions (your call)
corpus/packages/like event pages are sharded, keeping fan-out under the bound.Option 1 alone changes a safety constant; options 2/3 are structural. Happy to test any candidate on this host since it's a natural >1024-package reproducer.
Workaround considered locally
None clean: the runtime is digest-pinned by
managed-install/runtime, so patchingsiacapsule.pyin place would be refused by the tamper-evidence model — correctly, I'd add. We've left Continuity in the failed state pending an upstream fix.