Captures in this browser: sent captures keep their whole reading for ever, and each log entry rewrites the whole log #54

New issue

Closed

opened 2026-10-31 03:04:35 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-31 03:04:35 +00:00

Owner

What exists today

On the forge's main (678114c):

src/lib/store.js:75-118: a capture record carries read and data, both the full posting as read from the page (description included), apart from the page HTML. When it is sent, outbox.js:83-92 sets the state and drops the page (dropPage), but the record keeps read and data in full. Nothing removes sent records except the person, one by one or with Clear sent (src/captures.js:198-205). The lists use only data.title, data.company_name, data.location and reviewUrl of a sent record (captures.js:95-96, 114, lib/review.js:57-59).
store.list() (store.js:52-59) reads every record, sent ones included, on each badge recount (PR10), each dropPage and each unsentFor.
The manifest asks only storage (src/manifest.json:15), so the 10 MB quota applies; a full quota makes Keep fail with "storage full" (#16, fixed as a message, not prevented).
src/lib/log.js:14-25 add: reads the whole log (up to LIMIT = 1000 entries), appends one, writes it all back. A delivery logs about three entries per capture (outbox.js:53, 70, 74, 93, 98, 105, 109), so each capture costs three read-serialise-write cycles of the full log.

What would change

When a capture is sent, replace read and data with the shown fields only (title, company_name, location, url), as the page is already dropped. Postulo has the reading; the extension keeps the way back (reviewUrl).
Optionally (Decisions), remove sent records older than N days on the five-minute alarm.
Log: collect a delivery's entries in memory and write them in one add of several entries at the end (log.addMany), keeping the "never throws" rule; single events elsewhere stay as they are.

What it saves or protects

small (reliability): a sent capture shrinks to the few fields the lists show, so months of use cannot fill storage.local (10 MB in Chromium without unlimitedStorage, and a full store refuses new captures, #16); a delivery of N captures writes the log once instead of about 3N times, each rewrite being up to 1,000 entries (on the order of 100 kB of JSON)

Accessibility

must be checked: Captures in this browser and the popup's list keep showing a sent capture's title, company, place and review link, and Clear sent keeps working and announcing; guarded by the tests of captures.js and lib/review.js

Decided by the maintainer (2026-10-31)

slim sent captures now and remove them after 30 days; batch the log writes; keep the 1,000-entry limit

Decisions

Remove sent captures automatically? Recommended: slim them now, and remove after 30 days; the review link is in Postulo's own list by then.
Lower the log limit? Recommended: no; batching the writes is enough, and 1,000 entries is what a bug report wants.

Found by the efficiency and reliability audit of 2026-10-30 (finding PR11; index postulo/postulo#1108). Checked against main at daee30b15 (2026-10-30).

## What exists today On the forge's `main` (`678114c`): - `src/lib/store.js:75-118`: a capture record carries `read` and `data`, both the full posting as read from the page (description included), apart from the page HTML. When it is sent, `outbox.js:83-92` sets the state and drops the page (`dropPage`), but the record keeps `read` and `data` in full. Nothing removes sent records except the person, one by one or with *Clear sent* (`src/captures.js:198-205`). The lists use only `data.title`, `data.company_name`, `data.location` and `reviewUrl` of a sent record (`captures.js:95-96, 114`, `lib/review.js:57-59`). - `store.list()` (`store.js:52-59`) reads every record, sent ones included, on each badge recount (PR10), each `dropPage` and each `unsentFor`. - The manifest asks only `storage` (`src/manifest.json:15`), so the 10 MB quota applies; a full quota makes Keep fail with "storage full" (#16, fixed as a message, not prevented). - `src/lib/log.js:14-25` `add`: reads the whole log (up to `LIMIT = 1000` entries), appends one, writes it all back. A delivery logs about three entries per capture (`outbox.js:53, 70, 74, 93, 98, 105, 109`), so each capture costs three read-serialise-write cycles of the full log. ## What would change - When a capture is sent, replace `read` and `data` with the shown fields only (`title`, `company_name`, `location`, `url`), as the page is already dropped. Postulo has the reading; the extension keeps the way back (`reviewUrl`). - Optionally (Decisions), remove sent records older than N days on the five-minute alarm. - Log: collect a delivery's entries in memory and write them in one `add` of several entries at the end (`log.addMany`), keeping the "never throws" rule; single events elsewhere stay as they are. ## What it saves or protects small (reliability): a sent capture shrinks to the few fields the lists show, so months of use cannot fill `storage.local` (10 MB in Chromium without `unlimitedStorage`, and a full store refuses new captures, #16); a delivery of N captures writes the log once instead of about 3N times, each rewrite being up to 1,000 entries (on the order of 100 kB of JSON) ## Accessibility must be checked: *Captures in this browser* and the popup's list keep showing a sent capture's title, company, place and review link, and *Clear sent* keeps working and announcing; guarded by the tests of `captures.js` and `lib/review.js` ## Decided by the maintainer (2026-10-31) slim sent captures now and remove them after 30 days; batch the log writes; keep the 1,000-entry limit ## Decisions - **Remove sent captures automatically?** Recommended: slim them now, and remove after 30 days; the review link is in Postulo's own list by then. - **Lower the log limit?** Recommended: no; batching the writes is enough, and 1,000 entries is what a bug report wants. --- Found by the efficiency and reliability audit of 2026-10-30 (finding PR11; index postulo/postulo#1108). Checked against `main` at `daee30b15` (2026-10-30).

tiagoagueda added this to the 0.6.0 milestone

2026-10-31 03:04:35 +00:00

tiagoagueda added the

bug

performance

labels

2026-10-31 03:04:35 +00:00

tiagoagueda referenced this issue from a commit

2026-11-11 22:46:27 +00:00

Slim sent captures, remove them after 30 days, and write a delivery's log once

tiagoagueda referenced this issue from a pull request that will close it,

2026-11-11 22:46:28 +00:00