Watcher-Based Policy Invalidation & Sync

[mariajgrimaldi]

Description

Implement and document a Casbin watcher strategy to keep the enforcers’ in-memory policy state fresh. The watcher should notify enforcers when policies change and trigger a synchronization callback that aligns with our Policy Lifecycle Load/Clear approach.
MVP note: This must remain simple and reliable sufficient to validate the approach during the MVP, without complex orchestration.

Problem

• Notification-only today: The watcher broadcasts changes, but our callback only logs; no real sync occurs.
• Heavy reloads are costly: Blindly calling enforcer.load_policy() on every change may be too expensive.
• Risk of staleness: Without a proper callback, in-memory state can drift from the datastore and cause incorrect enforcement (and potential duplicates).

Requirements

1. Provide a minimal, MVP-ready watcher integration: redis-wather properly configured
2. Implement a synchronization callback that:
   • Prefers a lightweight refresh (e.g., filtered/targeted where feasible), falling back to a safe simple path when needed.
   • Coordinates with the Load/Clear lifecycle so both mechanisms stay consistent.
3. Make behavior configurable for MVP (if needed):
   • Enable/disable watcher.
   • Select simple full reload vs. lighter refresh if adapter support exists.
4. Document how the watcher is wired, what the callback does, and how it interacts with lifecycle and duplicate prevention.
5. Ensure compliance with MVP goals: prioritize correctness and predictability over optimization.

Acceptance Criteria

• On policy changes, the enforcer receives watcher notifications and performs a meaningful sync beyond logging.
• Under common change scenarios, the enforcer becomes fresh without requiring heavy reloads by default (fallback allowed).
• Tests show:
  • Watcher-driven sync updates in-memory policies appropriately.
  • No conflicts with Load/Clear lifecycle.
  • No duplicates introduced as a side effect.

Notes

• Related to Policy Lifecycle Load and Clear Management and Policy Duplicate Management the watcher can drive invalidation that lifecycle then resolves.
• Keep scope minimal for MVP; defer advanced strategies to post-MVP iterations.

[mariajgrimaldi]

I assigned you this issue to figure out the scope of this for the MVP @BryanttV. This also includes the appropriate default configuration for the watcher here: https://github.com/openedx/openedx-authz/blob/main/openedx_authz/settings/common.py#L31-L32

Let me know!

[mariajgrimaldi]

The watcher-based enforcer was replaced by syncenforcer approach. @BryanttV: let's close this once we merge #103 and remove the references of the redis-watcher from the repo. Thanks!

[MaferMazu]

I'll close this based that we closed #103