Release prep: v1.13.1 - The Fetch Queue Looks After Itself

README.md

@@ -1,6 +1,6 @@
 # DCCore
 
-**v1.13.0** · Python 3.10+ · Linux, Windows and macOS
+**v1.13.1** · Python 3.10+ · Linux, Windows and macOS
 
 An IRC DCC file-sharing daemon — a modern reimplementation of OmenServe, the mIRC script that has run these channels for twenty years.
 

defaults.py

@@ -21,7 +21,7 @@
 # 1. SYSTEM AND GLOBAL ENGINE SETTINGS
 # ---------------------------------------------------------------------
 DEBUG_MODE: bool    = False        # Print every raw line the bot sends to the server in its own window; noisy, for chasing a protocol problem
-SCRIPT_VERSION: str = "DCCore v1.13.0"
+SCRIPT_VERSION: str = "DCCore v1.13.1"
 
 # Where this bot came from. Defined once because two things say it: the CTCP
 # VERSION reply, and the header of every generated list. Before this there was

docs/ADMIN-CONSOLE.md

@@ -208,7 +208,7 @@ Waiting for acknowledgement...
 DCC Chat connection established
 
 Welcome to DCCore
-DCCore v1.13.0 - platform=posix python=3.10 rar=/usr/bin/rar
+DCCore v1.13.1 - platform=posix python=3.10 rar=/usr/bin/rar
 
 Enter Your Password:
 ```

docs/FUTURE.md

@@ -86,7 +86,7 @@ Two pieces were worth doing carefully rather than quickly, and one of them turne
 
 ### Quality
 
-- **6378 tests**, on Linux, Windows and macOS, Python 3.10, 3.12 and 3.14, in CI on every push and pull request — and a preflight script that runs the whole suite twice, the second time with the host's own tooling hidden, so a test that only passes on a developer's machine fails before it is pushed.
+- **6659 tests**, on Linux, Windows and macOS, Python 3.10, 3.12 and 3.14, in CI on every push and pull request — and a preflight script that runs the whole suite twice, the second time with the host's own tooling hidden, so a test that only passes on a developer's machine fails before it is pushed.
 - **Stdlib-only** — the daemon and its test suite need no third-party packages; Flask is required only for the optional dashboard.
 - **No reloaded module owns a lock** — `!rehash` re-executes a module body, so a module-level `threading.Lock()` is rebound while a thread is still inside it. Every lock in a reloaded module is allocated in `runtime.py` and bound by name, and `tests/test_no_reloaded_module_owns_a_lock.py` fails if a new one appears — the class, not the four instances that prompted it.
 - **A cross-list search index** — SQLite FTS5, built as each bot list is fetched, so the dashboard can filter every held list live rather than re-reading them at 2-11 seconds a keystroke.
@@ -138,13 +138,18 @@ fetched list is `!nickname <track>`, written by that bot when it built the
 list, so it still names whichever nick was current at build time. Copying that
 line into the channel sends the request to a nick that may not be there.
 
-We have the same problem in the other direction, and it is not hypothetical:
-`update_list.py` writes `!{config.NICKNAME}` into every line of our own list at
-build time, and `irc.py` rebinds `config.NICKNAME` to the alt nick on a 433.
-A rebuild while we are on the alt nick therefore ships a list whose every line
-names the alt nick.
-
-Open: what is the stable identity — the services account, the host, an operator
+We had the same problem in the other direction, and it was not hypothetical:
+`update_list.py` wrote `!{config.NICKNAME}` into every line of our own list at
+build time, and `irc.py` rebinds `config.NICKNAME` to the alt nick on a 433, so
+a rebuild while we were on the alt nick shipped a list whose every line named
+the alt nick. **This half is fixed (#376):** the list now names the configured
+nick (`ORIGINAL_NICK`, falling back to `NICKNAME`) however it is built, live or
+from a subprocess, so it survives the bot being on its alt nick at rebuild
+time.
+
+The sidebar half is still open: a bot that reconnects under its alt nick still
+shows there as a second bot, since nothing merges the two adverts. What is the
+stable identity to merge them on — the services account, the host, an operator
 mapping in settings? And is the fix to normalise at fetch time, to rewrite the
 request lines on the way out, or only to merge the two rows in the sidebar?
 

docs/INSTALL.md

@@ -400,6 +400,8 @@ That lists every setting the sample knows about and your file does not. Most of
 
 Nothing breaks if you skip this — every setting has a working default and the daemon runs fine without any of them being present. You simply will not know what became available. The changelog is the readable version of the same information.
 
+That diff only catches settings that are new. **`PAUSE_ON_UPDATE` is not new in v1.13.1, but its meaning changed**: it now pauses searching and sharing only for the few seconds a rebuilt list is being swapped in, not for the whole rebuild. If you were relying on the old whole-rebuild pause, turn on the new `PAUSE_FOR_WHOLE_UPDATE` setting to keep it.
+
 **5. Read the changelog.** [UPDATES-PUBLIC.md](UPDATES-PUBLIC.md) says what changed and, where it matters, what you have to do about it.
 
 **6. Verify before going live.**

docs/UPDATES-PUBLIC.md

@@ -2,6 +2,8 @@
 
 ## Unreleased
 
+## v1.13.1 — The Fetch Queue Looks After Itself
+
 - **Added: automatic list grabbing (off by default).** Turn on *Grab the lists of bots you have no list from* (`AUTO_GRAB_LISTS`, under *Grabbing lists*) and DCCore asks for the list of each bot that advertises one and whose list you do not have yet - politely: one at a time, at most one every 10 minutes, after a random wait of 5 seconds to 6 minutes, not at all if someone else just asked that bot, and never more than 3 tries per bot, 30 minutes apart. You can skip small or slow bots, bots in "servers only" mode are always skipped, and a list you remove is not fetched back.
 - **Added: a "New" mark on fetched lists in the List Browser.** A list you fetched and have not opened yet says *New*; opening it clears the mark, and a refreshed list is new again.
 - **Improved: with `AUTO_REFETCH_LISTS` on, lists from bots that show no date are refreshed too.** Such a bot never says its list changed, so its list was never refreshed; it is now fetched again once it is 14 days old. Bots that do show a date are still refreshed only when it changes.

docs/UPDATES.md

@@ -4,6 +4,8 @@ All version changes, optimizations, and bug fixes made over time in the DCCore p
 
 ## 🟨 Unreleased
 
+## 🟩 v1.13.1 (2026-09-24) - "The Fetch Queue Looks After Itself"
+
 ### 🧲 Lists are grabbed automatically, on AutoGet's rules (#926)
 
 Item 5 of #926, the last one. New `list_grab.py`: with `AUTO_GRAB_LISTS` on (off by default - it spends other