Skip to content

Fix thread safety and cache invalidation#849

Open
zsinnema wants to merge 2 commits intodevelopfrom
fix-thread-safety-cache-invalidation
Open

Fix thread safety and cache invalidation#849
zsinnema wants to merge 2 commits intodevelopfrom
fix-thread-safety-cache-invalidation

Conversation

@zsinnema
Copy link
Copy Markdown
Contributor

Implemented solution

Use contextvars and invalidate user cache (on delete/update user event from KC)
Also added a README about how this Django app works and how to use it

Breaking changes (select one):

  • The present changes do not change the preexisting api in any way
  • This PR and the issue are tagged as a breaking-change and the migration procedure is well described above

Possible deployment updates issues (select one):

  • There is no reason why deployments based on CloudHarness may break after the current update
  • This PR and the issue are tagged as alert:deployment

Documentation (select one):

  • The documentation has been updated to match the current changes
  • The changes included in this PR are out of the current documentation scope

@zsinnema zsinnema requested review from alxbrd and filippomc April 21, 2026 05:59
@zsinnema zsinnema changed the title Fix thread safety cache invalidation Fix thread safety and cache invalidation Apr 21, 2026
Copy link
Copy Markdown
Collaborator

@filippomc filippomc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The scope of this PR is unclear. I suspect it's a fix for cached users within kafka listener workflows but not so sure, as I'd expect a fix for Kafka listeners to circumvent cache by construction instead of invalidating the cache.


## Configuration

Add the following to your `settings.py` after importing the CloudHarness settings:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd mention that the preferred way to get started is to use harness-application

## Installation

```bash
pip install cloudharness-django
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might confuse and make the reader expect that cloudharness-django is on pip

Add the library's settings module to the **top** of your `settings.py`:

```python
PROJECT_NAME = "my-app" # must be set before the import
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not an issue with this specific PR, but having a name that's unrelated from the cloudharness configuration for the application can be confusing. get_current_configuration().name would be more consistent IMO

Run migrations once after installation:

```bash
python manage.py migrate
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably suggest the preferred way to run migrations (the init container with the lock, now in templates)

init_listener_in_background()
```

If Keycloak may not be reachable immediately (e.g. during container startup), use the background variant for services as well:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as well -> instead?


### Cache invalidation

When a user is deleted or deactivated in Keycloak the Kafka event handler calls `invalidate_user_cache()` to remove the stale cache entry before syncing. You can also call it directly:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this relevant for the user of the library or more interesting for the library developer? Also this is the first time the kafka event handler is mentioned


## Event-driven synchronisation

`KeycloakMessageService` consumes the `keycloak.fct.admin` Kafka topic. On each Keycloak admin event it dispatches to the appropriate sync method:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This deserves more context. The event based sync adds real time update of user properties, but it's not necessary for the users sync functionality to work in general

init_services()

# Start the Kafka consumer in a background thread
init_listener_in_background()
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional, and requires harness.dependencies.soft += events

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants