ctx.storage: enumeration + lifecycle for module_kv rows #39

New issue

Closed

opened 2026-08-16 00:24:31 +02:00 by julian · 0 comments

julian commented

2026-08-16 00:24:31 +02:00

Owner

Follow-up from the #38 review (non-blocking items deferred there).

Today ctx.storage caps each value (8 MB) but nothing bounds a module's total footprint: unbounded keys are allowed, there is no list/deleteAll, and rows belonging to a module that was removed or renamed stay in /data forever with no surface able to see them. updated_at_ms is written and never read.

What this issue wants:

Enumeration: a way to see what is stored — per module key listing (key, size, updated_at_ms), plus an admin-facing view of totals per module (natural home: the /system page, which already exists for exactly this class of diagnostics).
Cleanup: deleteAll(module) or equivalent, so rows for a removed/renamed module can be dropped deliberately.
Optionally a per-module total bound, once the enumeration exists to make it observable.

Explicitly NOT wanted (from the review): auto-delete on module load failure — a module that failed to clone this boot must not lose its state. Cleanup stays a deliberate, human-triggered act.

Follow-up from the #38 review (non-blocking items deferred there). Today `ctx.storage` caps each **value** (8 MB) but nothing bounds a module's total footprint: unbounded keys are allowed, there is no `list`/`deleteAll`, and rows belonging to a module that was removed or renamed stay in `/data` forever with no surface able to see them. `updated_at_ms` is written and never read. What this issue wants: - **Enumeration**: a way to see what is stored — per module key listing (key, size, `updated_at_ms`), plus an admin-facing view of totals per module (natural home: the `/system` page, which already exists for exactly this class of diagnostics). - **Cleanup**: `deleteAll(module)` or equivalent, so rows for a removed/renamed module can be dropped deliberately. - **Optionally** a per-module total bound, once the enumeration exists to make it observable. Explicitly NOT wanted (from the review): auto-delete on module load failure — a module that failed to clone this boot must not lose its state. Cleanup stays a deliberate, human-triggered act.

julian referenced this issue

2026-08-16 00:24:45 +02:00

Module-scoped persistent storage (ctx.storage) + docker update state survives restarts #38

julian referenced this issue

2026-08-16 18:21:03 +02:00

Follow-ups from PR #38 review: ctx.storage / docker update persistence nits #43

julian referenced this issue

2026-08-16 18:46:04 +02:00

Storage review follow-ups: boot-only prune, prune-then-persist, cap + persistence tests, named columns #44

julian referenced this issue from a commit

2026-08-17 00:32:08 +02:00

feat(storage): see what a module is holding, and drop what outlived it