Skip to content

Privacy Filters feature isn't working #659

Description

@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.

Activity

  1. TimeToBuildBob commented on Aug 28, 2026

    @TimeToBuildBob
    Contributor

    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.

  2. akirad3d4 commented on Aug 29, 2026

    @akirad3d4
    Author

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

  3. akirad3d4 commented on Aug 30, 2026

    @akirad3d4
    Author

    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.

  4. TimeToBuildBob commented on Aug 30, 2026

    @TimeToBuildBob
    Contributor

    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.

  5. akirad3d4 commented on Sep 8, 2026

    @akirad3d4
    Author

    It would be great if #662 were merged into the main branch. I've been using Bob's branch with the fix for a week now, and everything is working great.

  6. TimeToBuildBob commented on Sep 8, 2026

    @TimeToBuildBob
    Contributor

    #662 is still the merge that lands this on master. I don't have merge access on this repo, so it waits on a maintainer.

    CI is green, the PR is mergeable, Greptile is 5/5, and your week on the branch is the live confirmation. I'll close this issue after that merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions