Runtime data (profiles 30 GB, screenshots, recordings) lives beside server.js; move it to ADOM_BRIDGE_DATA_DIR with retention (adom-bridge#153)

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

From adom-bridge#153 (AdomLapper at 0.5 GB free): 34 GB of pup RUNTIME data - 257 Chrome profiles (30 GB), screenshots (2.4 GB), recordings (2 GB) - sat under pup's install dir, because pup writes profiles/, screenshots/, recordings/, sessions/ relative to server.js. On that box the dir was ab's dev staging tree, so the data outlived every install; on any busy box the same growth happens inside bridges-cache/puppeteer, and a bridge_install swap or refresh then either carries it along or drops it.

Ask: write runtime data to a DATA dir, not beside the code. ab's next release passes every bridge ADOM_BRIDGE_DATA_DIR (= %LOCALAPPDATA%\Adom Bridge\bridge-data<bridge>, created by ab, survives cache swaps and version bumps); please resolve profiles/screenshots/recordings/sessions under it (fall back to the current location only when the variable is absent), and give screenshots and recordings a retention policy of your own (ab's janitor does age/size pruning for its own dirs; the same shape - oldest first, newest kept - fits here). Profiles are the user's logged-in state: keep them, but a 257-profile pile means transient per-session profiles are never deleted; a profile that has not been used in N days is a candidate.

2 Replies

John Lauer · 2mo ago

Done in the Rust build, pup 2.0.420 (candidate on arav-rog now, insiders after the smoke run).

Resolution rule (pup_core::data_subdir): when ADOM_BRIDGE_DATA_DIR is set, profiles, sessions, screenshots and recordings live at <data>/profiles, <data>/sessions, <data>/screenshots, <data>/recordings. The first boot that sees the variable MOVES each legacy dir over by rename (~/.adom/pup-profiles, ~/.adom/pup-sessions, the exe-side screenshots/ and recordings/), so the user's adom-you logins carry; if a rename fails the legacy path stays in use (never two copies). Without the variable nothing changes. pup_status reports dataDirs (with dataDir: null when the variable is absent, which is what arav-rog shows today, ab not passing it yet) and retention.

Retention (pup_core::retention_sweep, run by the daily janitor two minutes after boot and every 24 h): screenshots older than 14 days or beyond 1 GB total, recordings older than 30 days or beyond 3 GB, oldest first, never a file touched in the last 10 minutes (a recording still being written). Profiles are unchanged from 2.0.413: the janitor reaps only leaked iso-* jars; named profiles are the user's call (pup_reap_profiles {staleDays} on request).

Both paths are unit-tested natively (move once, stable second resolve, fallback without the variable; sweep drops the old file, then the oldest over the cap, keeps the fresh one). The live move will be verified on the first ab that passes the variable. The Node build (public tier) does not have this yet; it moves with the next Node ship.

John Lauer · 2mo ago

Shipped: 2.0.420 introduced the data dir (ADOM_BRIDGE_DATA_DIR, pup_core::data_subdir) with profiles, sessions, screenshots and recordings under it, plus the retention sweep (screenshots 14 d / 1 GB, recordings 30 d / 3 GB). Since 2.0.445 the rolling pup.log lives there too (logs/pup.log, 2 MB, one rotation). Closing; ab passing the variable is tracked on the ab side.

John Lauer closed this · 2mo ago