tooling: auto-upgrade gallery-dl + yt-dlp before every run and weekly; document 2026-10-22 empty posts listing

TOOLING.md

@@ -283,6 +283,30 @@ loudly, verified with both a real captured rsync failure and unit tests.
 The other 22 release tags stay on gitea. Pushing them all to GitHub triggers
 one container build per tag, because each tag carries its own workflow file.
 
+## 2026-10-22 — gallery-dl auto-upgrade; posts listing went empty
+
+Scheduled and manual runs were failing quietly from early October: after the session was
+restored, `posts` listings for `heejin`/`kimxxlip` returned `No results` in ~3 s (a caught-up
+profile skips; it does not say that), while stories worked and the posts opened fine in the
+browser. The host was on gallery-dl 1.32.14; 1.32.17 (2026-10-17) lists "instagram: update
+`user` & `posts` query parameters". After upgrading, the profile lookup failed instead
+(`KeyError: 'data'`, `Requested user could not be found`) -- **unresolved when written**, see
+the end of this section.
+
+`scripts/gdl-upgrade.sh` (`pipx upgrade --include-injected gallery-dl`, so yt-dlp too) now runs:
+
+- at the start of every `gdl-cron.sh` run, after the session preflight and before any request;
+  logs `upgrade: up to date` or `upgrade: CHANGED a -> b`, and never fails the run;
+- weekly from `gdl-upgrade.timer` (systemd user timer, installed on `mattellite` with the
+  others -- systemd rather than cron, to match the rest of the host).
+
+It costs no Instagram requests. The trade-off: a bad upstream release is picked up
+automatically; roll back with `pipx install --force gallery-dl==<old>` and re-inject yt-dlp.
+
+**A `--min-interval` trap:** a run that returns `No results` still counts as a fetch, so the
+next run skips the source for 20 h. Re-run after a bad result with `--min-interval 0`
+(not `--force`, which also drops the probe cache).
+
 ## Guards — recreate these after a fresh clone
 
 Neither guard is versioned, so a new clone has **no protection at all**: