2 Commits

Include renames

Author	SHA1	Message	Date
tiennm99	cdf2295ef6	docs(canvas): correct CF DO limits in resize doc and plan ... Earlier docs assumed a 1 GB per-DO storage cap. Actual May 2026 free-tier limits per the CF DO docs: - 10 GB per Durable Object - 5 GB per account (the real Free-tier ceiling) - 2 MB per BLOB row - 1,000 req/sec soft cap per DO Practical effect: canvas can grow to ~70,000 × 70,000 on Free (was previously documented as ~32K × 32K). Existing 64 KB CHUNK_BYTES is well-suited: clustered writes (single pixels + image patches) minimize read-modify-write amplification; bigger chunks would only help uniform-random writes which isn't rplace's workload. No code change. Just doc accuracy.	2026-05-10 00:07:39 +07:00
tiennm99	c3f7c02f6d	feat(canvas): migrate canvas + cooldown storage to DO SQLite ... Move pixel state and rate-limit cooldowns out of Upstash Redis and into the existing CanvasRoom Durable Object's SQLite-backed storage. Worker becomes a thin validation/proxy; the DO does atomic cooldown check + pixel write + WS broadcast in one in-memory step. Why: eliminate external dependency, keep $0/month free-tier forever, exploit single-threaded actor for strong consistency without round-trips. Architecture: - canvas_chunks: 256 BLOB rows × 64 KB; CHUNK_COUNT derived from CANVAS_WIDTH × CANVAS_HEIGHT / CHUNK_BYTES so resize is config-only. - cooldowns: user_id → expires_at, 1% sample-rate lazy GC. - Worker forwards /api/canvas, /api/place, /api/ws to DO endpoints. - POST /admin/migrate-from-upstash: token-gated one-shot importer. Phases 1-3 code complete; Upstash dependency stays until prod migration runs and 7-day rollback window passes (Phase 4). Plan: plans/260509-2309-canvas-on-do-storage/	2026-05-09 23:53:21 +07:00