Skip to content

Back office redirects to the front office after updating to 9.0+ (core cache wiped after warm-up) #1867

Description

@mattgoud

Describe the bug

After a CLI update to PrestaShop 9.0+, the freshly updated shop's back office redirects to the front office: opening /<admin>/ (e.g. /admin-dev/) returns a 302 to //<lang>/ instead of the login page. The shop stays in that state (it does not self-heal), until a Symfony cache rebuild is triggered.

In PrestaShop 9.0 the BO login is a Symfony route (admin_login/login); when the Symfony prod cache is missing, the admin entry point can't boot and falls back to the front office.

Root cause

During the update, UpdateDatabase warms up the core cache (CoreUpgrader::warmupCoreCache(), gated by shouldWarmupCoreCache() = destination ≥ 9.0.0 && CLI), which builds var/cache/prod. But the later UpdateComplete task calls CacheCleaner::cleanFolders() (which clears var/cache/) after that warm-up, wiping the just-built prod container. The update finishes with an empty var/cache/prod (only a leftover <version><lang>.xml), so the 9.0 Symfony back office cannot start.

How I reproduced it (locally, mirrors the CI Upgrade CLI job)

  1. docker compose PrestaShop 8.1.7-8.1, then autoupgrade CLI local update to 9.0.0.
  2. Right after the update, curl -s -o /dev/null -w '%{redirect_url}' http://localhost/admin-dev/http://localhost/ (front office), 30/30 times.
  3. var/cache/prod/ contains only 9.0.0en.xml (no container).
  4. php bin/console cache:clear --env=prod → BO immediately works again (/admin-dev//admin-dev/login).

Impact

  • Merchants updating to 9.0+ can land on a broken back office until the cache is rebuilt.
  • CI: this is what makes the Upgrade CLI (and Upgrade UI) sanity should login in BO step flaky on 9.x destinations — the post-update sanity test lands on the front office and times out waiting for #email. Whether it passes depends on whether the first web hit manages to rebuild the container, hence the intermittent ~50% failures on the dev nightly and on PRs targeting 7.6.x.

Expected behavior

After the update completes, the shop should boot straight into the back office without any manual cache clear.

Fix

Warm up the core cache again after the final cleanFolders() in UpdateComplete (PR to follow).

Versions

  • autoupgrade: 7.6.x / dev
  • Destination: PrestaShop 9.0.0 (also affects 9.x in general)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Waiting for QA

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions