A change to the feed list can silently undo another made at the same time #153
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found in a code audit on 2026-10-09.
The catalogue and the server settings are written whole by
Ctx::store_cfg(src/main.rs:183), from a copy each writer took earlier. Nothing stops two writers overlapping, and the longest window isweb::add_feed(src/web.rs:1460-1483): it copies the config, then runsfind_feed(up to two fetches) andadd_one(another fetch, for the title), up to a minute or more, and then stores its copy.Anything stored meanwhile is written over: another person's new feed (it leaves their sidebar and is never scanned, though their subscription row stays), an unsubscribe that took a feed out, an admin's change to the settings, the scan's
follow_move(a feed's new address) or its category fromclassify,clean_directory. No error anywhere.The other writers:
add,rm,subscribe_opml,clean_directory,follow_move, the classify step inscan_one,patch_feed,remove_feed,patch_settings, andreload, which replaces the live copy from the database.Fix: one async lock in
Ctxheld from the copy to the store by every writer, withadd_feedtaking its copy after the fetches that find the feed.Fixed in
c426ab6: every change takes its copy through Ctx::edit_cfg, which holds a lock until store_cfg keeps it, and store_cfg accepts nothing else, so no writer can skip it. add_feed takes its copy after finding the feed. Test: two_changes_to_the_catalogue_at_once_both_keep. Left as a ponytail comment on the lock:ipx add,rmandimportwrite from a process of their own and are outside it. Deployed as 0.10.3-dev on 2026-10-09.