Repository navigation
Conversation
query_desktop_full (and the multidevice variant) sent the whole week or month as one TIMEINTERVAL, which Axios aborts at 30s on large databases. query_category_time_by_period already splits those ranges into days. Query one day at a time, then merge app/title/category/browser aggregates and sum durations. A single day stays one request.
Greptile SummaryThis PR prevents long desktop activity queries from exceeding the per-request timeout by splitting multi-day periods into sequential daily requests and recombining their results.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[Selected activity period] --> B[Split multi-day range into days]
B --> C[Run daily requests sequentially]
C --> D[Merge event groups and durations]
D --> E[Update activity store]
E --> F[Render summary and timeline]
Reviews (2): Last reviewed commit: "docs: record measured baseline for daily..." | Re-trigger Greptile |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #951 +/- ##
==========================================
+ Coverage 49.36% 50.47% +1.10%
==========================================
Files 45 46 +1
Lines 2769 2841 +72
Branches 625 648 +23
==========================================
+ Hits 1367 1434 +67
- Misses 1322 1326 +4
- Partials 80 81 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
CI-green and mergeable — waiting only on a maintainer click. This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted. |
Greptile 4/5 asked for profiling evidence on the week/month split. Axios timeout is per-request (30s). On a 31 MB / 4-month aw-server, July as one TIMEINTERVAL is 0.95s vs max daily 0.098s; sequential 31-day wall is 0.99s. The split cuts per-request time, not total work — same shape as query_category_time_by_period.
|
Addressed the Greptile 4/5 (missing profiling evidence) in On a 31 MB / 4-month aw-server, a July |
|
@greptileai review |
|
Automated merge handoff for
This head is ready for maintainer review and manual merge. Project monitoring marked it |
…1003) * feat(activity): always show Year period, remove showYearly setting The Year view was hidden behind a developer setting. Recent query performance work makes it usable, so show it unconditionally. Stale showYearly values in stored settings are skipped on load, since the settings API has no delete endpoint. * fix(activity): query active history one period per request In Year view each surrounding period is a whole year, so sending all 16 in one request can exceed the per-request timeout on large archives. Same approach as the desktop query split in #951. Addresses Greptile review on #1003. * fix(activity): only split active history requests for Year view Day/Week/Month keep the single batched request, so they don't pay for ~31 sequential round-trips. Addresses Greptile review on #1003. * fix(activity): bound active history requests to ~1 year of span each Replace the Year-only split with chunking by total span (<= 366 days per request). Measured on erb-m2 (aw-server v0.14.0b5, AFK data since 2022): all 16 years around a Year view in one request took 37s (past the 30s timeout), one year takes 6-8s. Day (30 days, 0.9s) and Week (31 weeks, 5s) stay a single request; Month and Last 30 days become 3 requests instead of one ~2.5 year request.
Problem
The month summary (
/activity/.../month/.../view/summary) times out at Axios's 30srequestTimeouton large databases (years of data). The client call that actually waits isquery_desktop_full, which sends the entire month as one TIMEINTERVAL.query_category_time_by_periodalready splits week/month ranges into days "to avoid timeout on slow queries". The summary's first query does not.The categorize-cache work in ActivityWatch/aw-server-rust#657 is a real win (~4× on heartbeat-shaped data) but is two orders of magnitude under 30s even on the naive path, so it cannot be this timeout. Issue ActivityWatch/aw-server-rust#629 closed on that merge; the month summary can still 30s-out until this query is split.
What this PR does
query_desktop_fullandquery_multidevice_fullby day for week/month/multi-day/year periods. A single day stays one request.query_category_time_by_period).app_events/title_events/cat_events/ browser aggregates (sum durations, re-sort, re-apply the 100-event limit).active_eventsare concatenated so the period timeline keeps its shape.Trade-off: merging per-day top-100s is not identical to a single month-wide top-100 (same trade-off
query_category_time_by_periodalready accepts). An app that is #101 every day still will not appear; an app that is #1 on one day still will.Tests
npx jest --selectProjects node --testPathPattern desktopQuerySplit --coverage=false— 9 passedFollow-up
Live confirmation on a 168 MB / 2y database that the month summary no longer hits the 30s Axios timeout. I do not have that reporter DB here.