# Celery

Celery handles notification delivery, email digests, LDAP retries, task
automation, attendance synchronization, guest lifecycle jobs, attachment cleanup
and payroll period opening.

## Configuration

```dotenv
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
CELERY_BROKER_URL=redis://127.0.0.1:6379/0
CELERY_RESULT_BACKEND=redis://127.0.0.1:6379/1
```

Tasks use JSON serialization, late acknowledgement, prefetch multiplier 1, a
25-minute soft limit and a 30-minute hard limit. `DatabaseScheduler` from
`django-celery-beat` is enabled, while the default periodic schedule is declared
in `backend/eusrr_backend/settings.py`.

## Development

```bash
cd backend
celery -A eusrr_backend worker -l info
celery -A eusrr_backend beat -l info
```

Run worker and Beat as separate processes. Migrations must include
`django_celery_beat` and `django_celery_results`.

```bash
python manage.py migrate
celery -A eusrr_backend inspect ping
```

There are no active custom queue routes in the current settings. Do not start a
worker restricted to `notifications,emails` unless matching routes have first
been configured and tested.

## Production

- run one Beat instance only;
- supervise worker and Beat with the deployment platform;
- use an authenticated/private Redis endpoint;
- preserve graceful shutdown so late-acknowledged tasks can finish or be redelivered;
- monitor queue depth, task runtime, retries and worker availability;
- deploy application code, migrations and workers as one compatible release.

Periodic jobs include daily/weekly notification digests, due task notifications,
scheduled task automations, LDAP retry processing, personnel actions, attendance
sync and guest visit maintenance. Check `CELERY_BEAT_SCHEDULE` for the exact
current names and intervals.

Tests use the in-memory/eager configuration from
`backend/eusrr_backend/settings_test.py`; tests should not require a live broker
unless they explicitly exercise broker integration.