9 Commits

Include renames

Author	SHA1	Message	Date
asepharyana	24dfb1c6b1	fix: fail-fast guard TELEGRAM_CHUNK_SIZE_BYTES <= 19MB (Telegram getFile limit 20MB) ... Chunk parts > 19MB are stored to Telegram but getFile cannot resolve files over 20MB ('Bad Request: file is too big'), making every part undownloadable (prod bug 2026-08-01: 48MB chunk -> download 500). - src/env.ts: reject TELEGRAM_CHUNK_SIZE_BYTES > 19922944 at startup (log error + throw), default changed 20MB -> 19MB - src/shared/utils/validation.ts: TELEGRAM_CHUNK_SIZE_MAX_BYTES constant; asSafeChunkSize now enforces the max at runtime (covers S3 multipart parts too) - test/env.test.ts: unit tests + subprocess fail-fast tests (48MB rejected, 19MB accepted) - test/helpers/setup-env.ts: pin safe chunk size so a stale .env can't break the suite - .env.example + CLAUDE.md: document the 20MB getFile limit	2026-08-01 13:06:42 +07:00
Claude	1484d5265d	refactor: merge BOT_TOKEN + ADDITIONAL_BOT_TOKENS into single BOT_TOKENS env + speed audit ... BOT_TOKENS env: - Single BOT_TOKENS env var (comma-separated) replaces BOT_TOKEN + ADDITIONAL_BOT_TOKENS - Backward compat: falls back to BOT_TOKEN + ADDITIONAL_BOT_TOKENS if BOT_TOKENS unset - Config exposes botTokens: string[] instead of botToken + additionalBotTokens - Updated env.ts, bot-pool.ts, docker-compose.yml, .env.example, CLAUDE.md, all tests Speed audit (S3 -> Telegram upload flow): - Hoisted 5 dynamic await import('../../../db/index') to top-level static imports in s3-controller.ts (3x) and web-api-controller.ts (2x) -> saves module resolution + async overhead on every upload - Removed stale UPLOAD_CONCURRENCY env from docker-compose.yml (already removed from env.ts in prior refactor) Upload flow is already concurrent: - streamBodyToTemp() uses Bun.file(path).writer() — O(1) memory, safe for multi-GB blobs - utils/chunked-storage.ts reads chunks serially but uploads concurrently with inFlight backpressure at effectiveConcurrency * 2 (= 16 with 8 bots) - bot-pool.ts: per-bot PQueue(concurrency=1), 8 bots = 8 concurrent uploads per file, selectBot() picks least-loaded, 429 detection + inner+outer retry loops - TELEGRAM_API_TIMEOUT_MS=120s — ample for 48MB chunks - Infrastructure chunked-storage.ts (DI-based, dead code) has serial upload trap — noted for future cleanup	2026-07-29 15:03:02 +07:00
MythEclipse	06844f1fa1	docs: update CLAUDE.md to include details on temporary file handling for API uploads	2026-05-18 22:03:55 +07:00
MythEclipse	cc3f85284b	docs: add dynamic image fetching details for unit tests in CLAUDE.md	2026-05-18 21:54:57 +07:00
MythEclipse	d58b2390ef	refactor: remove concurrency limit from Telegram upload queue and enhance media group handling	2026-05-18 21:54:39 +07:00
MythEclipse	b91b276214	feat: add support for batch uploads of media groups to Telegram with debounce handling	2026-05-18 21:31:20 +07:00
MythEclipse	825e969569	feat: implement multi-bot support for Telegram API with rate limit handling and add task queue for uploads	2026-05-18 21:18:16 +07:00
MythEclipse	721fa3db7d	feat: implement auto-retry for Telegram API requests on error 429 and update documentation	2026-05-18 21:02:38 +07:00
MythEclipse	cf55f6dee8	Initialize TeleUploader project with Bun, including configuration files and basic setup	2026-05-18 06:34:02 +07:00