AxiosError: timeout of 30000ms exceeded while trying to see activity for one month #629

Activity

1. TimeToBuildBob commented on Aug 25, 2026

   

   TimeToBuildBob

   on Aug 25, 2026

   Contributor

   More actions

   Opened #657 with the fix.

   Root cause: in was evaluating every event against every regex rule individually — ~1M evaluations for a typical month (50k+ events × 20 rules). Most events share identical app/title data, so the same matches were recomputed thousands of times.

   Fix: added a -based cache inside keyed on the serialized event data. Only the first occurrence of each distinct data fingerprint hits the regex engine; subsequent identical events reuse the cached category. For 50k events with ~200 distinct app/title pairs this reduces regex work from 1M to ~4k evaluations (~250×).
2. ErikBjare

   added a commit that references this issue on Aug 25, 2026

   perf(aw-transform): cache categorize results per event data to fix mo…

   ...

   This issue will close once commit 7429039 is merged into the 'master' branch.

   7429039
3. ErikBjare

   closed this as completedin #657on Aug 25, 2026
4. wojnilowicz commented on Aug 29, 2026

   

   wojnilowicz

   on Aug 29, 2026

   ContributorAuthor

   More actions

   Thanks. This fixes my error. I'm afraid that these optimizations to regex might not hold long enough, once I'll have even larger database.
   If I understood the fix correctly, still every event (instead of only events in the selected time period) in my database goes through regex evaluation.
5. TimeToBuildBob commented on Aug 29, 2026

   

   TimeToBuildBob

   on Aug 29, 2026

   Contributor

   More actions

   That's not how the query path works — regex never runs over the whole database.

   query_bucket() always fetches only the selected time range. The month view sets TIMEINTERVAL to that month, and the datastore query is:

   SELECT id, starttime, endtime, data
   FROM events
   WHERE bucketrow = ?
     AND endtime >= <month start>
     AND starttime <= <month end>

   (aw-datastore/src/datastore.rs get_events_inner, called from aw-query/src/functions.rs query_bucket.)

   categorize() then runs only on those events. Growing the historical database does not add regex work to a month query. What would make a month view slower is more events in that month, more distinct app/title pairs, or more category rules.

   The cache makes categorization scale with distinct app/title combinations in the period, not with raw event count or total DB size. The RAM bump you saw (20 MB → ~100 MB) is loading that month's events into memory, not the 168 MB sqlite file.

   If a month view starts timing out again because the period itself gets denser, that's a useful report — but total DB size alone shouldn't bring it back.