Bug Report: Docker Enterprise upgrade 3.30.2 - 3.31.0

Issue 1 - Application code not updated after image switch (old code masked by persistent volume)

After completing the image switch procedure (docker load + docker tag … latest + docker compose down/up with both compose files), containers started and DB migrations ran successfully, but the application kept running on the old 3.30.2 codebase (visible via app_v=3.30.2 in JS assets and /app/upgrade/VERSION file still showing 3.30.2). The site eventually threw “An Internal Error Has Occurred” after a server reboot.

Root cause: docker-compose.simple-install.yml mounts the entire application directory as a persistent named volume (app:/var/www/eramba). Docker only populates a named volume from the image on first creation; since the volume already existed from 3.30.2, the new 3.31.0 image code was never copied into it after the image switch - old code kept running against the new (already-migrated) DB schema.

Fix applied:

  1. Stopped eramba and cron (both mount the app volume).

  2. Ran a throwaway container from the new image with --entrypoint /bin/sh, mounting the volume at /target, and rsynced the code in, excluding app/upgrade/data/ and app/upgrade/logs/ to protect user data/attachments:

    docker run --rm --entrypoint /bin/sh -v docker_app:/target
    ghcr.io/eramba/eramba-enterprise:3.31.0-29
    -c “rsync -a --delete --exclude=‘app/upgrade/data/’ --exclude=‘app/upgrade/logs/’ /var/www/eramba/ /target/”

  3. Restarted eramba/cron — application then ran its normal migrations for 3.31.0 features (Awareness, SCIM, etc.) and came up on the correct version.

Suggestion: The image switch procedure (courses/98) should explicitly mention this volume-refresh step for existing installs, since a simple docker tag + up -d silently leaves the old code in place with no error or warning.


Issue 2 - All running Awareness Programs auto-stopped and marked “Migrated” during upgrade, undocumented

During the 3.31.0 data migrations, all in-progress Awareness Program training cycles were automatically stopped and flagged as “Migrated” (AddMigratedToAwarenessPrograms migration). This behavior is not mentioned anywhere in the 3.31.0 release notes and came as an unpleasant surprise - active/recurring onboarding trainings for new employees were interrupted without notice.

Suggestion: Please document this behavior explicitly in the release notes / upgrade guide, and ideally provide guidance on how to safely resume/recreate recurring programs (e.g., a “Recurring” cycle scoped only to newly-added employees, without re-enrolling users who already completed prior cycles).

Hi Alex, thanks.

  1. Old code after image switch: the image switch procedure linked in Step 6 (courses/98) includes docker volume rm docker_app before loading the new image. That step is exactly what refreshes the app code.

  2. Awareness programs marked “Migrated”: this is intended. The awareness module was rebuilt, and old programs are kept as read-only historic evidence. This is described in the feature thread linked from the release notes.

That said, you’re right that neither point is easy to spot at first glance. I’ll add both to the release notes.