feat!: replace redis with sqlite file storage

[derogab]

Summary

Replace the Redis server with a single SQLite file using Node's built-in node:sqlite module. Message reads and writes are marginally slower than an in-memory store, but for this workload the difference is irrelevant — and in exchange the bot loses an entire external service: no Redis container, no connection lifecycle, no extra dependency. Data management and storage also get simpler: history is plain rows in one queryable file, easy to inspect, copy and back up, instead of TTL-bound string-encoded lists in a separate server.

Changes

Storage

• Message history now lives in a messages table in a local SQLite file (SQLITE_PATH, default summarygram.sqlite), replacing Redis lists.
• Messages are kept forever; /summary and the daily cron only consider messages from the last 24 hours (previously the whole history expired 8 hours after the last message).
• Each message stores chat_id, user_id, username (nullable), user_firstname, user_lastname, message and created_at. Summaries display username, falling back to first name or user id.
• Messages containing ### are no longer truncated (columns replaced the old string-encoded format).

Code simplification

• Dropped the Storage class and its Redis-style connect/disconnect lifecycle: the db handle is opened lazily at module level and the storage functions are plain synchronous calls.
• Removed the chat: key prefix and the storage parameter threaded through every handler.

Deployment

• Removed the Redis container from docker-compose.yml; the app now bind-mounts ../data and reads/writes the db file there.
• Removed the redis npm dependency; Node.js >= 22.13.0 is now required for node:sqlite.
• Updated grammy, @types/node and TypeScript (7.x); renamed vitest config to .mts.

Breaking changes

• REDIS_URL is replaced by SQLITE_PATH.
• Requires Node.js >= 22.13.0.
• Existing Redis data is not migrated: history restarts empty.

Test plan

• npm run compile passes (TypeScript 7)
• npm test passes (27 tests, storage tests run against a real in-memory SQLite db)
• Smoke-tested the compiled storage layer against a real .sqlite file
• Deploy via docker compose -f docker/docker-compose.yml up -d and verify messages are stored in ./data/summarygram.sqlite and /summary works

---

Summary by cubic

Replaced Redis with a single SQLite file via Node’s node:sqlite to simplify deployment and remove an external service. Indexed queries, filtered stale chats, and run bounded startup ANALYZE to speed up /summary and the daily cron.

• New Features

  • Store chat history in a local SQLite file at SQLITE_PATH (default summarygram.sqlite). Each message saves chat_id, user_id, username (nullable), user_firstname, user_lastname, message, created_at; summaries display @username when present, otherwise first name or user id. Messages containing ### are preserved.
  • Simpler deploy and code: removed the Redis container and redis dependency; bind-mount ../data and set SQLITE_PATH. Dropped the Storage class and its connect/disconnect flow; storage calls are synchronous. Updated grammy, @types/node, and TypeScript.
  • Performance: added an index on (chat_id, created_at), made getActiveChats ignore chats with only old messages, and run ANALYZE at startup with analysis_limit so SQLite uses skip-scan plans without growing startup cost.
  • CI: use Node 24 in the docker-publish workflow to support node:sqlite.

• Migration

  • Replace REDIS_URL with SQLITE_PATH.
  • Require Node.js >= 22.13.0.
  • Existing Redis data is not migrated.
  • Docker: mount ../data and set SQLITE_PATH=/data/summarygram.sqlite.

^{Written for commit c39e90f. Summary will update on new commits.}

[cubic-dev-ai]

Review completed against the latest diff

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 5 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 13 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/controller/core.ts">

<violation number="1" location="src/controller/core.ts:127">
P2: Every incoming message now performs a synchronous SQLite write that blocks the Node.js event loop, and each /summary / cron digest performs synchronous reads as well. Because the store is synchronous (node:sqlite DatabaseSync) and often lives on a mounted volume, storage latency can stall all concurrent message processing, transcription, and LLM calls in the process. This is a deliberate simplification, but it trades the previous non-blocking async storage for blocking I/O in the hottest path. Consider keeping the sync API for simplicity or, if responsiveness matters, moving writes/reads to an async worker pool or a write queue — at minimum the tradeoff is worth confirming against expected message volume.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>