Image Storage transfer can remain at 0% when scheduled work does not execute

Summary

An Image Storage transfer-back operation can remain active without processing images. The operation is expected to either begin restoring files or enter a visible failure state. Instead, the inspected workflow can continue reporting an active transfer with an unchanged count, leaving the user unable to recover locally stored originals through the plugin.

Customer context

• Product / area: Optimole Pro, Image Storage transfer back
• Version: Customer version not provided; inspected source is 4.2.10
• Environment: WordPress; Windows 10 and Firefox reported by ticket metadata
• Integration / third party: The customer reports no caching plugin or server cache and reports cron as active
• Reported error / symptom: Transfer remains stuck before visible progress after password protection was removed
• Impact: Cloud-stored images cannot be restored to the site's local media storage through the plugin

Reproduction notes

Reported workflow:

1. Start an Image Storage sync/transfer-back operation.
2. Remove the site's password gate and retry while images are publicly accessible.
3. Observe that the transfer remains active before visible progress.

Support later confirmed public image access. The customer reports no cache and active cron. No controlled runtime reproduction was performed; the scheduler-failure condition is confirmed from source, while its occurrence on this site remains inferred.

Diagnosis

Conclusion

The transfer state is persisted as active before background work is scheduled, while the scheduler result is discarded. Polling derives activity from that persisted setting and remaining image count rather than from worker execution or a progress heartbeat. This directly permits a non-progressing operation to remain active indefinitely when the scheduled action is absent, stale, or not executing. The ticket's exact environmental trigger is unknown because no logs or usable screenshot were available.

Where this likely occurs

• inc/media_offload.php — Optml_Media_Offload::move_images() lines 1854–1934: stores transfer metadata and active status, invokes schedule_action() without evaluating its result, then returns the persisted activity state.
• inc/media_offload.php — Optml_Media_Offload::schedule_action() and is_scheduled() lines 1946–1970: delegates to Action Scheduler or WP-Cron and treats the presence of a scheduled record as sufficient evidence of recoverable work.
• inc/media_offload.php — Optml_Media_Offload::maybe_reschedule() lines 197–219: skips recovery whenever a scheduled record exists, without checking whether image counts are advancing.
• assets/src/dashboard/utils/api.js — callSync() lines 479–590: polls every ten seconds while status is true and count is nonzero, with no no-progress boundary.
• Git history: commit 52ebcd90 refactored the current scheduling/REST path; the inspected behavior is present in tags from v4.0.0 through v4.2.10.

Engineering notes

The same bulk-processing path handles offloading and rollback, although this report concerns transfer back. Action Scheduler is preferred when available, with WP-Cron as fallback. A pending Action Scheduler record can suppress maybe_reschedule() even when no batch advances. Persistent batch exceptions also retry the same step without a terminal attempt limit in Optml_Media_Offload::start_processing_images() at lines 2035–2101. The customer reports cron as active, but Action Scheduler state, request logs, worker execution, and server resource limits were not captured.

Test coverage status

tests/test-media.php includes test_image_sync() at lines 326–346 and test_image_rollback() at lines 348–358, but these call media operations directly. No relevant coverage was found during inspection for scheduler insertion failure, stale pending actions, non-advancing jobs, REST polling, or terminal handling of persistent batch failures.

What to verify or explore next

• May be worth reproducing a rollback with scheduler insertion returning failure and confirming the REST count/status sequence.
• May be worth reproducing a pending Action Scheduler record whose worker does not run, while WP-Cron requests continue normally.
• If reproducible, checking Action Scheduler records and Optimole rollback logs for the affected operation could distinguish missing dispatch from a repeatedly failing first batch.
• The direct rollback suites in tests/test-media.php and a status-poll integration path are relevant verification surfaces.

Unknowns / follow-up

The customer's Optimole version, image count, PHP/WordPress versions, Action Scheduler backend, first rollback log error, and exact scheduler state are unavailable. The original screenshot was not retrievable through the sanctioned ticket-image tool.

Confidence

Confidence: 90/100

Two independently verifiable defects in the Optimole WordPress plugin match the reported stalled rollback and disabled Image Storage UI. The screenshot and site-specific logs are unavailable, so confidence is based on direct source-path evidence rather than a customer-site reproduction.

---

Source: HelpScout #3411333716
Generated by bug-report-triage (ID: bug-report-triage_6a7f1f81ead033.88694331)

Start with Optml_Media_Offload::move_images(), schedule_action(), is_scheduled(), and maybe_reschedule() in inc/media_offload.php, then inspect callSync() in assets/src/dashboard/utils/api.js. Run the rollback-related tests in tests/test-media.php and reproduce scheduler insertion failure or a stale pending action. Done should include regression coverage showing that a non-advancing transfer does not remain active indefinitely and instead recovers or reaches a visible terminal state.