Privacy Filters feature isn't working

[akirad3d4]

I've been using the beta versions (not research) for a while now, but I still haven't been able to get the privacy filters to work. The redact and drop actions don't work, so events that should match the filters are saved unchanged, no matter what. I tried building a server on my own, but ran into the same problem.

[TimeToBuildBob]

The rules were saving. They were never loaded into the engine that actually filters inserts.

DatastoreWorker starts with an empty PrivacyFilterEngine. Insert/heartbeat already call filter_event, and RefreshPrivacyFilter knows how to reload settings.privacy_filters — but nothing called refresh after save, and startup never read the persisted key. So drop/redact rules looked broken on stock beta and on a self-built server.

Fix: #662 — reload on save/delete of that key, and load it at worker startup. A datastore test now saves a drop rule, inserts a matching event, and asserts it is not stored (no explicit refresh call).

Once that merges, a saved drop rule should actually drop. I'll close this only after that lands, not just because the PR exists.

[akirad3d4]

Well, I checked #662. Now the drop and redact actions actually work. Thank you.

[akirad3d4]

It seems to me that the redact action uses a simple replacement without the ability to extract information from the pattern and apply it during the replacement. It would be great if it worked the same way as the filters in awatcher.

[TimeToBuildBob]

Yes — redact was whole-field only. Capture-group replacement is in #665, with the same $1 / $name semantics as awatcher.

Example: pattern ● (.*) and replacement $1 turns "● file.rs - Visual Studio Code" into "file.rs - Visual Studio Code". A rule with no capturing groups still replaces the whole field, so existing REDACTED rules stay the same.

The original "filters never apply" bug is still #662; I'll close this issue after that merges, not because the capture-group PR exists.