Allow WP-CLI wp optimole media rollback_images command to execute when offload_media is set to rollback state #1161

Activity

1. pirate-bot

   added

   feature-request-triage

   on Sep 24, 2026
2. pirate-bot

   added the

   Improvement

   issue type on Sep 24, 2026
3. pirate-bot

   added

   customer reportIndicates the request came from a customer.Indicates the request came from a customer.

   on Sep 24, 2026
4. selul

   self-assigned this

   on Oct 9, 2026
5. milicavs commented on Oct 11, 2026

   

   milicavs

   on Oct 11, 2026

   More actions

   🧪 QA steps and test sandbox

   When Transfer back from Optimole is started in the dashboard but the background transfer stalls (for example on a host where WP-Cron doesn't run), the WP-CLI command wp optimole media rollback_images can't finish it: it refuses to run with "You need to have the offload_media option enabled in order to use this command".

   Requires: your own Optimole account (API key) with Image Storage, and a terminal on the sandbox for WP-CLI (SSH, from the sandbox's page in SandyWP).

   Step	Build	Bot check
   Reproduce the bug	Optimole 4.2.16 (released)	✅ Reproduced: with a rollback in progress, the command stopped with the offload_media error
   Verify the fix	PR #1173 build 0e438a7	✅ Fixed: the same command ran and printed "All images have been uploaded to your media library"; it is still refused when no rollback was started

   On the sandbox:

   • https://qa-optimole-wp-1161.s1-sandywp.com runs the release. Sign in to SandyWP and use the sandbox's Auto Login.
   • WP-Cron is turned off, like the customer's host, so a transfer started from the dashboard never moves on its own.
   • The Media Library already has three 1600px images to offload.
   • Tools → QA Logs shows debug.log, which the public site can't read.
   • If it has stopped after a day without use, the next qa-playground run brings it back.
   • The bot had no Optimole account: it set the "rollback in progress" state directly and had no offloaded images to move.

   Reproduce on Optimole 4.2.16:

   1. Optimole → connect with your API key.
   2. Optimole → Settings → Image Storage: turn on offloading.
   3. In the terminal, run wp optimole media move_to_optimole (the dashboard's offload can't run without WP-Cron).
   4. Back in Image Storage, click Transfer back from Optimole. The progress stays at 0%.
   5. In the terminal, run wp optimole media rollback_images.

   • Bug: Error: You need to have the offload_media option enabled in order to use this command, and the images stay on Optimole.

   Verify the fix on the same sandbox:

   1. Download the PR build above, then go to Plugins → Add New Plugin → Upload Plugin and click Replace current with uploaded.
   2. Repeat the steps above from step 2.

   • Fixed: the command shows a progress bar and ends with "All images have been uploaded to your media library". Each image's File URL in Media → Library is back on /wp-content/uploads/…. Plugins still shows 4.2.16, since the build has no version bump.

   Edge cases

   • Image Storage off and no transfer started: rollback_images is still refused with the offload_media error.
   • move_to_optimole while a transfer back is in progress: still refused.
   • Account at its offload limit: rollback_images still runs (only offloading stops at the limit).
   • Run the command twice at once in two terminals: the second stops with "Another image transfer is running. Wait for it to finish, then run this command again.", and no image gets a -1 copy in uploads.

   Fix: #1173 (open)
6. pirate-bot commented on Oct 11, 2026

   

   pirate-bot

   on Oct 11, 2026

   Last edited by pirate-bot

   CollaboratorAuthor

   More actions

   QA agent — 🟢 Passing checks · WP-CLI completes dashboard-started rollbacks without duplicate restores in the tested scenarios.

   With a seeded Optimole account and mocked cloud responses, the candidate resumed dashboard-started rollback and restored all 11,001 lightweight image fixtures. The base build rejected the same stalled-rollback state. Quota checks and competing command/background transfers behaved as expected, with no duplicate files. All six outcomes and the PR’s 17 added tests passed; live-account and distributed-database coverage remain follow-ups.

   Worth a human look

   1. Repeat rollback with a real Optimole Image Storage account and the customer’s full-resolution 11,000+ media library.
   2. Exercise transfer locking on real HyperDB/LudicrousDB and multi-primary database deployments.
   3. Try bulk transfers on a database driver without advisory-lock support; the PR’s simulated fallback test passed here.
   4. Check simultaneous single-image moves and bulk rollback; the code review notes that the unchanged single-image path does not take this new lock.

   Checks (6 passed)

   • ✅ Starting Transfer back from Optimole in Image Storage with WP-Cron disabled persists offload_media=disabled and an active rollback, with the transfer still at 0%.
   • ✅ wp optimole media rollback_images shows progress and finishes with All images have been uploaded to your media library after dashboard-started rollback, including at the offload limit and in the reported 11,000+ image scenario.
   • ✅ After the command completes, every selected image is restored to wp-content/uploads and its Media Library File URL is local, with no offloaded metadata remaining.
   • ✅ An active image-moving lock refuses the command with Another image transfer is running. Wait for it to finish, then run this command again.; a merely scheduled or ended worker does not prevent rollback.
   • ✅ Competing command and background rollback attempts restore each image once, with no -1 copies in wp-content/uploads; skipped background steps move and schedule nothing while the moving lock is held.
   • ✅ With Image Storage off and no rollback active the command refuses with the offload_media error; move_to_optimole remains refused during rollback and stops at the account offload limit.

   Full report, evidence and session trail