Captures: binding a capture to an existing listing leaves its review data on the decided capture #523

New issue

Closed

opened 2026-10-01 10:47:22 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-10-01 10:47:22 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, checking every path that decides a capture.

Checked again on 2026-10-01 against main at 0a5cad587: still present. The field and its comment are now at jobs/models.py:1127-1133; jobs/history.py, jobs/capture_views.py and jobs/remembered.py:354 have not moved.

Capture.learning holds what a waiting capture's review learns from, "and nothing once it is decided" (jobs/models.py:1124-1130, #267). Saving, discarding and bulk discarding all empty it. bind_capture, the fourth way a capture is decided, marks it accepted and writes only status, posting and updated_at, so the remembered hints and the page's place digests stay on the row for as long as the capture exists, read by nothing.

Where: jobs/history.py:239-241 (bind_capture); the other decision paths: jobs/capture_views.py:369 and 376 (save, after remembered.at_review empties it at jobs/remembered.py:354), jobs/capture_views.py:449-452 (discard), jobs/capture_views.py:480 (bulk discard). Called from jobs/capture_views.py:412.
What happens: a person reviews a capture, recognises the advert, and binds it to the listing they already have. The capture becomes ACCEPTED with its learning JSON intact: the hint entries and, where the source was not kept, the bounded list of the page's places and digests.
Why it matters: the model states a rule one of four paths does not keep, and each decision path sets the capture's fields by hand, so the next field that must change on a decision has four places to be added and one already forgotten.
Fix: set locked.learning = {} in bind_capture and add "learning" to its update_fields. Better, move "decide a capture" into one helper in jobs/ that the save, bind and both discard paths call, so status and learning change together.

Done when

A test in tests/test_listing_history.py, beside the existing bind_capture tests, that gives a pending capture a non-empty learning, binds it, and asserts learning == {} after refresh_from_db(). It fails today.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, checking every path that decides a capture. Checked again on 2026-10-01 against `main` at `0a5cad587`: still present. The field and its comment are now at `jobs/models.py:1127-1133`; `jobs/history.py`, `jobs/capture_views.py` and `jobs/remembered.py:354` have not moved. `Capture.learning` holds what a waiting capture's review learns from, "and nothing once it is decided" (`jobs/models.py:1124-1130`, #267). Saving, discarding and bulk discarding all empty it. `bind_capture`, the fourth way a capture is decided, marks it accepted and writes only `status`, `posting` and `updated_at`, so the remembered hints and the page's place digests stay on the row for as long as the capture exists, read by nothing. - **Where:** `jobs/history.py:239-241` (`bind_capture`); the other decision paths: `jobs/capture_views.py:369` and `376` (save, after `remembered.at_review` empties it at `jobs/remembered.py:354`), `jobs/capture_views.py:449-452` (discard), `jobs/capture_views.py:480` (bulk discard). Called from `jobs/capture_views.py:412`. - **What happens:** a person reviews a capture, recognises the advert, and binds it to the listing they already have. The capture becomes `ACCEPTED` with its `learning` JSON intact: the hint entries and, where the source was not kept, the bounded list of the page's places and digests. - **Why it matters:** the model states a rule one of four paths does not keep, and each decision path sets the capture's fields by hand, so the next field that must change on a decision has four places to be added and one already forgotten. - **Fix:** set `locked.learning = {}` in `bind_capture` and add `"learning"` to its `update_fields`. Better, move "decide a capture" into one helper in `jobs/` that the save, bind and both discard paths call, so status and `learning` change together. ## Done when - A test in `tests/test_listing_history.py`, beside the existing `bind_capture` tests, that gives a pending capture a non-empty `learning`, binds it, and asserts `learning == {}` after `refresh_from_db()`. It fails today.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:47:22 +00:00

tiagoagueda added the

enhancement

tier

labels

2026-10-01 10:47:22 +00:00

tiagoagueda referenced this issue

2026-10-03 01:58:43 +00:00

A kept page follows its capture, then the listing it became, and goes when that listing goes #664

tiagoagueda referenced this issue from a commit

2026-10-06 13:15:58 +00:00