mirror of
https://github.com/calibrain/shelfmark.git
synced 2026-11-15 07:08:26 +00:00
splitsec2
2668705bfa
Two small changes that stop Shelfmark from opening a new HTTPS connection for requests that go to the same host over and over. Anna's Archive download counts. Every search result gets its count from `/dyn/md5/inline_info/<md5>`, and each of those was a bare `requests.get`, so a search with 50 results opened 50 TCP and TLS connections to the mirror. `search_books` also runs once per title variant, and the variants of one book mostly find the same files, so the same md5 was looked up again for every variant that found it, and again when the release list was reopened. The lookups now share one `requests.Session`, and a successful count is kept for five minutes in a bounded `CacheService` (the same class the metadata cache uses, as its own instance, so it does not depend on the metadata cache toggle). A lookup that fails or comes back without a count is not cached, so it is retried on the next search just like today. The URL, headers and 5 second timeout are unchanged. Debrid clients. Real-Debrid, AllDebrid, Debrid-Link and TorBox also used the bare `requests` helpers. The download handler polls `get_status` every two seconds for each active job, so every poll was a fresh TLS handshake with the debrid API. Each of those modules now keeps one `requests.Session` and sends its API calls through it, the way the qBittorrent, Deluge, Prowlarr and Newznab clients already do. Headers, timeouts, `verify` and error handling are still passed per call exactly as before. The existing tests that patched `<module>.requests.get/post/request` now patch `<module>._session.<verb>` instead; nothing else in them changed. How I checked it: each change has a test that fails on main and passes here. They count the requests that reach `requests.Session.request` and the sessions built while doing it, with no network. On main, three polls of each debrid client build three sessions, and two overlapping batches of AA results look `bbb` up twice. There are also tests for the count cache expiring (with a faked clock) and for a failed lookup not being cached. Full suite: 4432 passed, 48 skipped. ruff and basedpyright are clean on the changed files. I also looked at caching `/api/releases` on the server and left it out. The release modal already caches each book's results per source and content type in the browser for five minutes (longer for IRC and slskd through `cache_ttl_seconds`), and that cache survives closing and reopening the modal, so reopening it does not run a new search today. A server cache would only help after a page reload, and it would quietly undo the modal's "apply filters" and manual search refetches, which drop the browser cache on purpose, unless the frontend also learned to send a bypass. That did not seem worth it for this PR.