Conversation
Greptile SummaryThe PR keeps the in-memory privacy filter synchronized with its persisted setting during startup and settings changes, while restoring the prior filter state if a transaction fails.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains; the current rollback path restores the transaction-start filter engine, and non-absence loading errors preserve the active rules. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Start worker] --> B[Load persisted privacy filters]
B --> C[Begin transaction]
C --> D[Snapshot active engine]
D --> E[Process settings and event commands]
E --> F{Commit succeeds?}
F -- Yes --> G[Keep updated engine]
F -- No --> H[Restore transaction-start engine]
G --> C
H --> C
Reviews (4): Last reviewed commit: "fix(datastore): restore privacy engine f..." | Re-trigger Greptile |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #662 +/- ##
==========================================
+ Coverage 70.81% 79.75% +8.93%
==========================================
Files 51 66 +15
Lines 2916 5680 +2764
==========================================
+ Hits 2065 4530 +2465
- Misses 851 1150 +299 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
macOS CI failure was the known
|
|
@greptileai review |
|
@greptileai review |
The webui saved settings.privacy_filters, but DatastoreWorker started with an empty engine and never reloaded on SetKeyValue. Insert and heartbeat paths filtered correctly against rules that were never loaded, so drop/redact rules appeared to do nothing (ActivityWatch#659). Reload the in-memory engine when that key is written or deleted, load it at worker startup, and keep RefreshPrivacyFilter as an explicit path.
The reopen assertion already passed on windows-latest; remove_file then hit ERROR_SHARING_VIOLATION because the worker thread still held the SQLite handle. Unique-ify the temp db and treat cleanup as best-effort.
A SetKeyValue/DeleteKeyValue on settings.privacy_filters reloads the in-memory engine from the still-open transaction. If the batched commit later fails, SQLite rolls back but the engine keeps the rules from the rolled-back write, so subsequent inserts filter against state that no longer exists on disk — including running unfiltered after a rolled-back delete. Reload from the durable connection on the commit-failure path so the engine matches what actually persisted.
The reload treated every get_key_value error as "key deleted" and emptied the engine. A transient InternalError from the query would therefore disable filtering entirely and let the events these rules exist to exclude get stored. Clear only on NoSuchKey; warn and keep the current engine otherwise.
67195c5 to
6bf2934
Compare
|
Rebased onto current master ( |
A privacy-setting mutation reloads the engine from the still-open transaction. On commit failure, re-querying the durable connection and keeping the current engine on read error left a rolled-back delete's empty engine in place, so later inserts ran unfiltered. Restore the snapshot taken at transaction start instead. Recovery then does not depend on a second read succeeding.
|
Greptile 3/5 leftover: a rolled-back delete plus a failed durable reload could keep the uncommitted (empty) engine, so later inserts ran unfiltered.
|
|
@greptileai review |
|
CI-green and mergeable (Greptile 5/5) — 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. |
Summary
Privacy filter rules saved from the webui never actually applied.
DatastoreWorkerstarts with an emptyPrivacyFilterEngine, insert/heartbeat paths do filter against that engine, andRefreshPrivacyFilterreloadssettings.privacy_filters— but nothing called refresh after save, and startup never loaded the persisted key. The UI could save drop/redact rules all day; matching events were stored unchanged.Fixes #659.
What changed
settings.privacy_filtersis written or deleted (SetKeyValue/DeleteKeyValue).RefreshPrivacyFilteras an explicit path (HTTP settings endpoints still call it as belt-and-suspenders).set_key_valueactually drops a matching insert (no explicit refresh), and the same rule still applies after reopen.Test plan
cargo test -p aw-datastore --test datastore