Downgrade to 2.58.4 from 2.59 causes data base errors and failure on boot

[ChrisAAAllard]

Bug description
Downgrading the application code from 2.59.0 to 2.58.x against a database already migrated to 2.59 leaves the schema and code out of sync, with no guard or clear error. The 2.59 migration removes the Credential Manager (drops dojo_cred_user/dojo_cred_mapping and the dojo_system_settings.enable_credentials column), but 2.58 code still expects them.

This produces two failures:

1. The initializer crashes during pghistory trigger configuration because 2.58 still registers Cred_User with pghistory:

Configuring pghistory triggers

File "/app/dojo/management/commands/complete_initialization.py", line 36, in handle
configure_pghistory_triggers()
File "/app/dojo/auditlog/services.py", line 467, in configure_pghistory_triggers
call_command("pgtrigger", "enable")

psycopg.errors.UndefinedTable: relation "dojo_cred_user" does not exist

django.db.utils.ProgrammingError: relation "dojo_cred_user" does not exist

2. Even once the app starts, a runtime banner appears on multiple pages because the code queries a column the 2.59 schema removed:

"Warning: Unable to load system settings from database: column dojo_system_settings.enable_credentials does not exist LINE 1: ...ings"."risk_acceptance_notify_before_expiration", "dojo_syst... ^. Default values are being used. Please check your database configuration and run migrations if needed."

Steps to reproduce

1. Run DefectDojo 2.59.0 so the database is migrated to 2.59 (Credential Manager removed).
2. Move the code back to 2.58.x against the same database (e.g., a docker compose pull/checkout landing on the older tag), then rebuild.
3. Run docker compose up -d and watch docker compose logs -f initializer.
4. See the initializer exit 1 on the pghistory step; if the app is forced up, see the enable_credentials banner on pages that read system settings.

Expected behavior
A downgrade against a newer schema should be detected and blocked with a clear message identifying a code/database version mismatch. At minimum the initializer error and the system-settings banner should point to the version mismatch as the cause.

Deployment method (select with an X)

• Docker Compose
• Kubernetes
• GoDojo

Environment information

• Operating System: Ubuntu 24.04.04
• Docker Compose
• DefectDojo version: downgraded from 2.59.0 to 2.58.4 (database at 2.59)

Additional context
Root cause was a downgrade, not data corruption. Recreating dojo_cred_user let 2.58 start but left the enable_credentials banner; the actual fix was recreating the missing table from the Credential Manager schema. Filing because the failure modes give no indication that a version/schema mismatch is the cause.

[ChrisAAAllard]

While I am up and running now I do want to stress this bug be taken into account for the subsequent v3 release to ensure a clean roll back up to v3 that hopefully should be resilient to the issues triggered by the downgrade. I understand it may not be fair to have you also account for the particular fix I implemented in the meantime for my deployment however if its possible to ensure either situation (broken with no fix or with my bandaid solution of recreating the table) is accounted for that would be appreciated.

Command used to recreate the table:

sudo docker compose run --rm --no-deps --entrypoint python uwsgi manage.py shell -c "
from django.db import connection
from dojo.models import Cred_User
with connection.schema_editor() as se:
    se.create_model(Cred_User)
print('CREATED dojo_cred_user')
"

[ChrisAAAllard]

Additional issue that has cropped up since downgrading. Deleting seems to not be functional, this one I am not sure where to look as far as error logs and such. *Tried to upload and .mp4 and its having some issues but here is the error. This occurs after attempting to delete just a single findings either independently or as part of merging. removing from groups and closing does appear to still work

not super descriptive just internal 500. I may look at wiping the database schema and starting fresh unless you guys want to keep me around for a test case. :]

[mtesauro]

Couple of suggestions:

If you haven't already, turn on debug logging - it's super verbose so I'd only use it for these kind of situations.
https://github.com/DefectDojo/django-DefectDojo/blob/2.58.4/readme-docs/DOCKER.md#logging

If you want to check your DB schema against a vanilla install of DefectDojo 2.58.4, I just created this using tbls which is a super handy tool generally:
https://github.com/k1LoW/tbls

HTH

dbdoc-v2.58.4.tar.gz

[ChrisAAAllard]

Just fyi I have copied over the django folder to a different folder with a new name and brought the instance up fresh with a new database schema. (the old folder still has the broken one). Only thing I ported over was the user table to allow users to sign in as before and keep any scripts using the api keys valid.

As far as resolving my issues we are square, though happy to act as a case study for bugs to address for the future and things to do smoke and regression testing for going forward

[valentijnscholten]

Some notes as more people might end up in this situation because of the revocation of 2.59.0.

1. Migrations in 2.59.0
   In 2.59.0 there we 4 database migrations. These files might give you an understanding of what schema changes were made in 2.59.0:

• https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/db_migrations/0265_remove_stub_finding.py
• https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/db_migrations/0266_remove_credential_manager.py
• https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/db_migrations/0267_usercontactinfo_ui_use_tailwind.py
• https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/db_migrations/0268_release_authorization_to_pro.py

2. Future upgrade to 3.0.0 after downgrading to 2.58.4
   If you have manually recreated tables/fields, you may run into some problems on the future upgrade to 3.0.0. Just be aware and make a backup before you upgrade.

3. People running Defect Dojo from source will still (at the time I am writing this) get 2.59.0 unless you explicitly build 2.58.4 (or lower).

[igarridot]

Clean rollback 2.59.0 → 2.58.x via the Django migration framework

Sharing what worked for us, since the 2.59 schema changes are actually reversible. You can roll back without recreating any table by hand (which is what leaves the enable_credentials banner and the broken deletes mentioned above).

2.59.0 added exactly four dojo migrations on top of 2.58.4's 0264:

• 0265_remove_stub_finding
• 0266_remove_credential_manager
• 0267_usercontactinfo_ui_use_tailwind
• 0268_release_authorization_to_pro

All four are reversible. Reversing them recreates dojo_cred_user / dojo_cred_mapping, the enable_credentials column, the default_group* columns and the Cred_User pghistory triggers — i.e. exactly the schema 2.58.x expects — so both the initializer crash and the runtime banner disappear.

The catch: 2.58.x no longer ships the 0265–0268 files, so it can't reverse them. You must run the reverse with 2.59.0 code (the image/checkout you're downgrading from), before switching back to 2.58.x.

Steps (Django CLI, deployment-agnostic)

0. Back up the database.

1. Confirm what's applied beyond the 2.58 baseline. The quick check, run with 2.59.0 code:

python manage.py showmigrations dojo | tail -n 6
# 0265-0268 should be [X]

The thorough check (catches any third-party app migration too) — run with a 2.58.x image, whose on-disk migrations are the 2.58 baseline, so applied − disk is exactly the 2.59 delta:

python manage.py shell -c "
from django.db.migrations.loader import MigrationLoader
from django.db.migrations.recorder import MigrationRecorder
from django.db import connection
disk = set(MigrationLoader(connection).disk_migrations)
applied = set(MigrationRecorder(connection).applied_migrations())
for m in sorted(applied - disk): print(m)
"
# expected, and nothing else:
# ('dojo', '0265_remove_stub_finding')
# ('dojo', '0266_remove_credential_manager')
# ('dojo', '0267_usercontactinfo_ui_use_tailwind')
# ('dojo', '0268_release_authorization_to_pro')

2. Reverse to 0264, with 2.59.0 code (preview first, then apply):

python manage.py migrate dojo 0264 --plan
python manage.py migrate dojo 0264

3. Verify:

python manage.py showmigrations dojo | tail -n 6
# 0265-0268 are now [ ]

4. Now deploy 2.58.x. Its migrate is a no-op (DB already at 0264) and the pghistory step no longer crashes because dojo_cred_user exists again.

Notes

• Stop celery / workers (scale to 0) while reversing, to avoid writes mid-migration.
• Data in the dropped tables (Stub Findings, Credential Manager) was already removed by the 2.59 upgrade; the reverse recreates them empty.
• 0268's RunPython backfill of is_superuser / is_staff is not undone (its reverse is a no-op), so audit elevated users afterwards.