5 Commits

Include renames

Author	SHA1	Message	Date
asepharyana	62021397e0	chore: sync port references and docs to 4000s infra	2026-08-02 16:19:30 +07:00
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
Claude	ea87397801	refactor: remove upload and web-api routes, migrate to new controller structure ... - Deleted `upload.ts` and `web-api.ts` routes, consolidating logic into dedicated controllers. - Updated import paths in tests to reflect new controller structure. - Refactored Telegram API utilities to utilize a bot pool for improved bot management and error handling. - Enhanced environment variable tests to ensure additional bot tokens are correctly populated. - Adjusted S3 bucket configuration tests to align with new controller imports. - Updated Telegram queue implementation to reflect new infrastructure organization.	2026-07-29 07:28:30 +07:00
Claude	1422318f0a	fix: enhance test setup and environment configuration for improved reliability	2026-07-28 22:44:08 +07:00