1.8 KiB
1.8 KiB
checkId, plugin, severity, tags
| checkId | plugin | severity | tags | ||||
|---|---|---|---|---|---|---|---|
| check.db.migrations.pending | stellaops.doctor.database | warn |
|
Pending Migrations
What It Checks
Looks for the __EFMigrationsHistory table and reports the latest applied migration recorded there.
This runtime check does not diff the database against the assembly directly; it tells you whether migration history exists and what the latest applied migration is.
Why It Matters
Missing or stale migration history usually means a fresh environment was bootstrapped incorrectly or schema changes were never applied on startup.
Common Causes
- Startup migrations are not wired for the owning service
- The database was reset and the service never converged the schema
- The service is using a different schema owner than operators expect
How to Fix
Docker Compose
docker compose -f devops/compose/docker-compose.stella-ops.yml logs --tail 200 doctor-web
docker compose -f devops/compose/docker-compose.stella-ops.yml exec postgres psql -U stellaops -d stellaops -c "SELECT \"MigrationId\" FROM \"__EFMigrationsHistory\" ORDER BY \"MigrationId\" DESC;"
Confirm the owning service calls startup migrations on boot instead of relying on one-off SQL initialization scripts.
Bare Metal / systemd
journalctl -u <service-name> -n 200
dotnet ef migrations list
dotnet ef database update
Kubernetes / Helm
kubectl logs deploy/<service-name> -n <namespace> --tail=200
kubectl exec -n <namespace> <postgres-pod> -- psql -U <db-user> -d <db-name> -c "SELECT COUNT(*) FROM \"__EFMigrationsHistory\";"
Verification
stella doctor --check check.db.migrations.pending
Related Checks
check.db.migrations.failed- diagnose broken runs before retryingcheck.db.schema.version- validates the resulting schema shape