Expand description
Redis-backed pagination cache for list commands.
FicHub shares its Redis instance with the bot. When a user runs /recs,
/search, /ask, /quote, or /requests, the full result list is stored
under a short-lived session key; !next/!prev/!page X then read from
Redis instead of re-calling the API (no DB hammering).
Key layout: archivist:session:<user_id>:<session_id> → JSON array of
PageEntry (the whole list, so pagination is trivial).
Response cache: archivist:askcache:<sha256(q)> → JSON AskResponse,
and archivist:searchcache:<sha256(qs)> → JSON SearchResponse. These
protect the public bot from hammering the LLM (/ask) and the API
(/search). Only Ok responses are cached; a Redis failure never blocks
the request (best-effort, like log_search).
Structs§
- Page
Cache - Redis-backed cache for paginated lists.
- Page
Entry - A single paginated-list entry: the raw item plus a stable ordering index.
- Page
List - A paginated list session stored in Redis.
- Search
LogEntry - One search-log row: everything needed to reproduce/debug a search request.
Constants§
- ASK_
CACHE_ TTL_ SECS - How long cached
/askresponses live (LLM generation is expensive — a popular public bot would otherwise hammer Ollama with identical queries). - SEARCH_
CACHE_ TTL_ SECS - How long successful
/searchresponses live (cheap, but rate-limits / transient API errors should not force a re-fetch for every caller). - SEARCH_
LOG_ CAP - Max entries kept per day in the search log.
Functions§
- page_
count - Number of pages for a list.
- slice_
page - Pagination helper: slice a list for a given page.