Skip to content

Fix: Resolve Django 5.x database access during app initialization warning - #44

Merged
peterfarrell merged 6 commits into
mainfrom
fix/django-5-app-init-warning
Jun 19, 2026
Merged

Fix: Resolve Django 5.x database access during app initialization warning#44
peterfarrell merged 6 commits into
mainfrom
fix/django-5-app-init-warning

Conversation

@ricosalomar

Copy link
Copy Markdown
Collaborator

Fix: Resolve Django 5.x database access during app initialization warning

1. Root Cause & Context

In Django 5.0+, a new RuntimeWarning was introduced to discourage database operations during the application registry population phase (inside AppConfig.ready() or during module imports):

RuntimeWarning: Accessing the database during app initialization is discouraged. To fix this warning, avoid executing queries in AppConfig.ready() or when your app modules are imported.

In django-heralder, the ready() method of HeraldConfig called Notification.objects.get_or_create(...) to automatically discover and register notification classes. This triggered the warning and caused issues such as potential connection deadlocks in some test suites and startup warning noise.

2. Solution (Signal-Based Registration)

This PR implements an idiomatic, safe, and self-contained adjustment inside src/herald/apps.py:

  • Deferred Database Access via post_migrate: We connected the notification auto-discovery database registration loop to Django's post_migrate signal instead of running it directly inside ready().
  • No Warning Suppression Required: Since database queries are no longer executed during standard startup or application loading, this completely eliminates the RuntimeWarning without silencing other system warnings.
  • Test Suite Alignment: Inside tests/test_usernotifications.py, we updated the setUp() method to use get_or_create() instead of .save() when instantiating Notification test records. Since test environments run migrations and dispatch post_migrate signals automatically, the notifications are already cleanly pre-registered in the test DB, avoiding potential uniqueness IntegrityErrors.

These changes are fully backward-compatible and have zero negative performance impact.


Verification & Testing Plan

  1. Unit Tests: Ran the full test suite in a local virtual environment:
    PYTHONPATH=src .venv/bin/python manage.py test
    • Results: All 77 unit tests passed successfully with zero warnings/errors.
  2. Startup Checks: Ran manual system check and migration tasks:
    PYTHONPATH=src .venv/bin/python manage.py check
    PYTHONPATH=src .venv/bin/python manage.py migrate
    • Results: Clean startup with zero warning output.

@peterfarrell
peterfarrell self-requested a review June 17, 2026 22:09
@peterfarrell peterfarrell added the bug Something isn't working label Jun 17, 2026
@peterfarrell

Copy link
Copy Markdown
Owner

@ricosalomar looks great -- generated some unit tests to cover some of the code (we never had any for apps.py)

@peterfarrell
peterfarrell merged commit 1d23930 into main Jun 19, 2026
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants