1.12.2 — Healthy deploys no longer roll back for housekeeping

2026-08-18

django-mojo 1.12.2 narrows rollback to real release failures, keeps healthy canaries serving when auxiliary systems or deployment bookkeeping fail, and preserves durable failure evidence for the incidents that do roll back.

Fixed

• Rollback is now reserved for release-critical failures: dependency or framework installation, migrations, static collection, render, nginx/application configuration, web-service restart, and real health/sanity probes.
• MojoSec, nginx security-include refresh, auxiliary services, timers, cron, retired-name cleanup, and log ownership now create linked level-5 deploy warning incidents and continue.
• A MojoSec failure restores the new release’s django.inc routing baseline instead of resurrecting the previous release’s routes.
• Deployment identity or callback failures stop fleet progression but leave a healthy canary serving so the parent job can record the control-plane failure.
• Canary failures that genuinely require rollback now preserve a bounded, line-by-line redacted command-output tail and create a linked level-7 incident before rollback.