In Django, what is AppConfig.ready() for, and what should you avoid doing inside it?

## Where ready() sits in startup `django.setup()` populates the app registry in three phases, each walking `INSTALLED_APPS` in order: 1. **Import apps** — create an `AppConfig` for each entry. Importing models here is not allowed. 2. **Import models** — import each app's `models` submodule. After this, `apps.get_model()` works. 3. **Run `ready()`** — call each app config's `ready()` method. So `ready()` is the **first moment every model exists**. That makes it the hook for startup wiring that needs models but must not run at import time. ## What belongs in ready() - **Importing signal receivers**, for example `from . import signals`, so `@receiver` decorators connect. The docs also allow connecting with a string sender such as `sender="scheduling.Appointment"`. - **Registering system checks** with `django.core.checks.register`, as `django.contrib.admin` does. - **Light configuration** that reads settings or model metadata, never data. ## What to avoid: the clinic-booking example Imagine a `scheduling` app whose config caches clinic opening hours at startup: ```python from django.apps import AppConfig class SchedulingConfig(AppConfig): name = "scheduling" def ready(self): from .models import Clinic # Do not do this: a query at app initialization self.opening_hours = {c.pk: c.hours for c in Clinic.objects.all()} ``` This breaks in several ways, all named in Django's documentation: | Problem | Why it happens | |---|---| | `migrate` crashes on a fresh database | `ready()` runs before `migrate` has created the `scheduling_clinic` table | | `manage.py test` queries production | the test database is created later; startup still uses the configured `DATABASES` | | every command gets slower | `ready()` runs for `shell`, `check`, `makemigrations` and all others | | data goes stale | the dict is built once per process and never refreshed | | a `RuntimeWarning` appears | Django warns that accessing the database during app initialization is discouraged | The fix is to load the data **lazily**, inside the request or task that needs it, or cache it with the cache framework and an expiry. ## ready() is not guaranteed to run once Django's docs say that in the usual process `ready()` is called once, but "in some corner cases, particularly in tests which are fiddling with installed applications, `ready` might be called more than once". Code in it should therefore be **idempotent**: connecting a receiver twice without a `dispatch_uid` could fire it twice, and appending to a global list would duplicate entries. Either write idempotent code or guard it with a flag on the config. ## Other pitfalls - **Doing the work in `apps.py` at module level** instead of inside `ready()` runs it in phase 1, where importing models raises `AppRegistryNotReady`. - **Forgetting the config is used**: if `INSTALLED_APPS` lists a package and `apps.py` defines two `AppConfig` subclasses without `default = True`, Django uses a plain default config and your `ready()` never runs. - **Long-running work** such as starting threads or opening network connections belongs in the serving process's own startup path, not in every management command. ## Checklist for reviewing a ready() method - Does it only **import or register** things, such as receivers, checks or lookups? - Does it run **any query**, directly, through a manager, a model method such as `save()`, or raw SQL through `django.db.connection`? If so, move it. - Would running it **twice** change behaviour? If so, make it idempotent or guard it with a flag on the config. - Does it depend on **another app's** `ready()` having run? Apps run `ready()` in `INSTALLED_APPS` order, so such a dependency is fragile and should be removed rather than solved by reordering. - Is it **cheap**? It runs for every process and every management command. ## What an interviewer is listening for A middle candidate knows `ready()` runs after models load and uses it for receivers. A senior one explains why queries there are dangerous (every command, wrong database, stale data), recognises the warning, and writes it idempotently.