fix(stats): stop showing 0 MiB for tiny media and scan media once per stats run - #476
Conversation
formatSize rendered 0 < size < 0.5 MiB as "0 MiB" next to a non-zero file count; it now reads "<1 MiB". calculate_and_store_statistics derives the archive-wide media count and DB size total from the grouped per-(account, chat) rows, NULL-chat rows included, instead of two extra scans over media. Adds a route test for a cached blob that carries the media counts map but no bytes map.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: GeiserX/Telegram-Archive/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughArchive media totals now come from grouped per-chat rows, including NULL-chat rows. The viewer displays positive sizes below 0.5 MiB as ChangesArchive statistics
Media size formatting
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Low Merge Risk: ⚪ Minimal · up to The statistics and display changes are ready to merge after normal checks. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Description checkExplanation The description explains the problem, implementation, tests, database aggregation changes, and compatibility considerations, but it does not follow the required template. It omits the Type of Change, Database Changes, Data Consistency Checklist, Testing checklist, Security Checklist, and Deployment Notes sections. Full details: Docstring CoverageExplanation Docstring coverage is 77.78% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 9 functions across 4 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🐳 Dev images published!
The dev/test instance will pick up these changes automatically (Portainer GitOps). To test locally: docker pull drumsergio/telegram-archive:dev
docker pull drumsergio/telegram-archive-viewer:dev |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #476 +/- ##
=======================================
Coverage 94.96% 94.96%
=======================================
Files 29 29
Lines 12318 12319 +1
=======================================
+ Hits 11698 11699 +1
Misses 620 620
🚀 New features to boost your workflow:
|
…per-chat maps Semantic port of upstream GeiserX#473 and GeiserX#476 for our one-account-per-archive layout (maps keyed by chat id, not account:chat). /api/stats returned the cached blob as is, so every login - including share tokens and viewer accounts restricted to a few chats - received the archive-wide totals and per_chat_message_counts, the id and message count of every archived chat. - The per-chat maps (messages, and now downloaded media count and bytes) are scoping input only: stripped from /api/stats and /api/stats/refresh. - A restricted viewer's chats, messages, media and storage are summed over its visible chats (fail closed). A blob written before the media maps existed omits the two media figures, and the popup hides those rows rather than showing 0 or archive-wide numbers. - The stats job reads downloaded media in one grouped scan instead of three; totals still count rows without a chat id. - formatSize shows "<1 MiB" instead of "0 MiB" for tiny totals. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Problem
The statistics popup showed "0 MiB" of storage next to a non-zero file count whenever the downloaded media added up to less than half a MiB. The daily statistics job also scanned the downloaded media three times: a count, a size sum, and the per-(account, chat) grouping, although the grouping already carries both figures. And no test covered a cached blob that holds the per-chat media counts map but not the bytes map, the case where a restricted viewer must get neither media figure.
Fix
formatSizeinindex.htmlreturns<1 MiBwhen the size is above 0 and below 0.5 MiB. Zero still reads0 MiBand every other value renders as before. A node test runs the real function: 0, 0.29, 0.5 and 12.3 give0 MiB,<1 MiB,1 MiBand12 MiB. The last two were pinned from the output before this change.calculate_and_store_statisticsadds upmedia_filesand the DB size total from the grouped rows, including rows with a NULLchat_id, which appear in neither map. The two standalone queries are gone. The stored keys and values stay the same. The mocked test now expects 4executecalls. A new test on a real SQLite adapter seeds one NULL-chat row and one row that was never downloaded, then checks that the totals equal the map sums plus the NULL-chat row.test_stats_account_scoped.pywrites a blob with the counts map and no bytes map. A restricted principal gets neithermedia_filesnortotal_size_mb; an unrestricted one still gets the archive-wide figures. The route code did not change. The test pins the existingandguard: switching it toorfails only this test.What it deletes / overwrites / forgets
cached_statsblob is rewritten the same way it was before, with the same keys and values.For review
SUM(file_size)used to come back as aDecimal. Now the total is the sum of Python ints, the same way the per-chat bytes map was already built.total_size_mbcould differ in the last rounded digit only in a rare tie, and SQLite behaves exactly as before. The Postgres-parametrised tests skip locally and run in CI.<1 MiBalso shows in the per-chat badge, but the badge only renders when the size is above 0, so a chat with no media still shows no badge.Summary by CodeRabbit