Problem
makeabilitylab/settings.py configures the LOGGING file handler with an absolute, container-specific path:
'handlers': {
'file': {
'class': 'logging.handlers.RotatingFileHandler',
'filename': '/code/media/debug.log',
...
},
}
Django evaluates LOGGING at startup (django.setup()), and several loggers reference the file handler. On any host where /code/media/ doesn't exist, startup raises:
FileNotFoundError: [Errno 2] No such file or directory: '/code/media/debug.log'
ValueError: Unable to configure handler 'file'
This is invisible in normal local dev and on the servers because /code is the bind-mount target and media/ exists there — but it makes the settings module fragile anywhere else.
How it surfaced
The first GitHub Actions CI run (added in #1280) failed at django.setup() with exactly this error, before any test could run. Worked around in makeabilitylab/settings_test.py by swapping the file handler for a logging.NullHandler so the test suite never depends on a writable log path. That fixes tests, but the underlying source-level fragility remains for any non-/code deploy or tooling.
Related: the /code/media/debug.log location is itself a documented finding in the security/perf audit (logs land under MEDIA_ROOT, i.e. publicly served at /logs/ per docs/DEPLOYMENT.md — an accepted design trade-off, separate from this robustness bug).
Suggested fix
Make the path derive from BASE_DIR (or an env var) and ensure the directory exists / degrade gracefully if it doesn't. Options, smallest first:
'filename': os.path.join(BASE_DIR, 'media', 'debug.log') — still requires media/ to exist, but no longer assumes /code.
- Wrap the file handler so a missing directory falls back to console-only instead of crashing startup.
- Move the log out of
MEDIA_ROOT entirely (ties into the audit's logging discussion) — larger change, coordinate with CSE IT since /logs/ exposure is intentional.
Effort: low (option 1). Priority: low — robustness/hygiene, not user-facing. Note the prod /logs/ exposure design before relocating the file.
Problem
makeabilitylab/settings.pyconfigures theLOGGINGfilehandler with an absolute, container-specific path:Django evaluates
LOGGINGat startup (django.setup()), and several loggers reference thefilehandler. On any host where/code/media/doesn't exist, startup raises:This is invisible in normal local dev and on the servers because
/codeis the bind-mount target andmedia/exists there — but it makes the settings module fragile anywhere else.How it surfaced
The first GitHub Actions CI run (added in #1280) failed at
django.setup()with exactly this error, before any test could run. Worked around inmakeabilitylab/settings_test.pyby swapping thefilehandler for alogging.NullHandlerso the test suite never depends on a writable log path. That fixes tests, but the underlying source-level fragility remains for any non-/codedeploy or tooling.Related: the
/code/media/debug.loglocation is itself a documented finding in the security/perf audit (logs land underMEDIA_ROOT, i.e. publicly served at/logs/perdocs/DEPLOYMENT.md— an accepted design trade-off, separate from this robustness bug).Suggested fix
Make the path derive from
BASE_DIR(or an env var) and ensure the directory exists / degrade gracefully if it doesn't. Options, smallest first:'filename': os.path.join(BASE_DIR, 'media', 'debug.log')— still requiresmedia/to exist, but no longer assumes/code.MEDIA_ROOTentirely (ties into the audit's logging discussion) — larger change, coordinate with CSE IT since/logs/exposure is intentional.Effort: low (option 1). Priority: low — robustness/hygiene, not user-facing. Note the prod
/logs/exposure design before relocating the file.