Summary
During transfer back from Optimole Cloud, an offloaded image can remain unavailable after its local restoration fails. The expected result is that the image remains recoverable and its page continues displaying it; the reported result is a 404 from both the Optimole delivery URL and the corresponding uploads URL. This leaves broken images in published content and can leave neither delivery path usable for the affected media.
Customer context
Product / area: Optimole, Image Storage transfer back
Version: The same account previously reported the offload failure on 4.2.9; the currently installed version is unknown. The inspected repository is 4.2.10.
Environment: WordPress site using Optimole Cloud image offloading; other WordPress and server versions are unknown.
Integration / third party: A cache plugin was mentioned by support; the screenshot also shows a page-builder environment, but relevance is unverified.
Reported error / symptom: Two images display as broken. Support observed 404 responses from their Optimole delivery URLs and original uploads URLs.
Impact: Published article content contains two unavailable images.
Reproduction notes
Reported sequence and status:
- The site previously used Optimole Cloud-only image offloading and was directed to transfer images back.
- Open the affected published article after that incident.
- Observe two broken image elements.
- Support reported that both the Optimole delivery URLs and corresponding uploads URLs returned 404.
Repository confirmation: the current rollback flow can continue page processing after cloud lookup or download failure leaves the local file unrestored. No isolated runtime reproduction was performed. Missing evidence includes the installed version, transfer status, rollback logs, and attachment metadata.
Diagnosis
Conclusion
The current rollback path contains a definite state-consistency defect matching the reported dual-404 symptom. Offloading removes the local files, while multiple transfer-back failures record an attachment error and skip restoration. For page-associated rollback work, the caller then updates the page regardless of restoration success. This can advance page state or persist an origin reference while the local file is still absent. Version 4.2.10 added retries for attachment errors, but the inspected flow still does not couple page advancement to successful restoration.
Where this likely occurs
- User-visible surface:
Optimole > Settings > Image Storage, during Transfer back from Optimole Cloud, followed by image rendering on published content.
inc/media_offload.php — Optml_Media_Offload::rollback_and_update_images() lines 840–904: cloud lookup or download failures set optimole_rollback_error and continue without restoring the local file.inc/media_offload.php — Optml_Media_Offload::start_processing_images() lines 2057–2066: update_page() runs after rollback_and_update_images() without using its success result.tests/test-media.php — Test_Media::test_image_processed() lines 297–316: the normal offload test confirms the local attached file is removed.tests/test-media.php — Test_Media::test_rollback_retry_clears_errors() lines 360–393: 4.2.10 coverage confirms retry eligibility for failed attachments, but not page state or references after failure.- Git history:
40ec3aa4 introduced clearing rollback errors on retry and shipped in v4.2.10; 060fd3fe is the 4.2.10 release commit. The unconditional page update predates that release and remains in the inspected tag.
Engineering notes
The same account previously reported broken thumbnails and dual 404s after enabling cloud-only storage on Optimole 4.2.9. That prior report led to the retry work tracked in closed issue Codeinwp/optimole-wp#1090. Current source retries attachments marked with rollback errors, but page processing and attachment restoration remain separate state transitions. This report concerns two residual images after that earlier incident; whether the site's transfer-back operation completed is unknown. Cache or page-builder involvement was not established and is not required for the confirmed control-flow defect.
Test coverage status
Happy-path offload and restoration coverage exists in tests/test-media.php, including Test_Media::test_image_processed(), Test_Media::test_image_sync(), and Test_Media::test_image_rollback() at lines 297–358. Test_Media::test_rollback_retry_clears_errors() at lines 360–393 covers re-querying failed attachments. No relevant coverage was found during inspection for a download or sideload failure followed by page processing, persisted page references after a failed restoration, or completion state with unresolved rollback errors.
What to verify or explore next
- Reproduce an offload followed by a forced cloud lookup or download failure during transfer back, then inspect the attachment file, page content, rollback metadata, and displayed URL.
- Repeat the transfer on 4.2.10 and confirm whether retry restores the attachment while the previously processed page remains consistent.
- Run the media test suite with failure-path coverage around
rollback_and_update_images() and start_processing_images().
- Confirm whether the affected references are stored in normal post content or page-builder metadata.
- Compare the affected behavior on 4.2.9 and 4.2.10 to establish the remaining regression boundary.
Unknowns / follow-up
The current installed plugin version, transfer completion status, exact failing delivery URLs, attachment metadata, rollback logs, and page-builder storage location are unavailable. The screenshot confirms broken elements but does not expose network details. Customer-site access was not used.
Confidence
Confidence: 86/100
The missing logs control matches documented operation-scoped behavior, but the dual-404 image failure aligns with a definite rollback control-flow defect in the current plugin and with the same account's earlier offload/restore incident. Version 4.2.10 retries failed attachments, yet the inspected page-processing path can still advance after restoration failure.
Source: HelpScout #3401282656
Generated by bug-report-triage (ID: bug-report-triage_6a6988e6f0ed29.96483252)
Summary
During transfer back from Optimole Cloud, an offloaded image can remain unavailable after its local restoration fails. The expected result is that the image remains recoverable and its page continues displaying it; the reported result is a 404 from both the Optimole delivery URL and the corresponding uploads URL. This leaves broken images in published content and can leave neither delivery path usable for the affected media.
Customer context
Product / area: Optimole, Image Storage transfer back
Version: The same account previously reported the offload failure on 4.2.9; the currently installed version is unknown. The inspected repository is 4.2.10.
Environment: WordPress site using Optimole Cloud image offloading; other WordPress and server versions are unknown.
Integration / third party: A cache plugin was mentioned by support; the screenshot also shows a page-builder environment, but relevance is unverified.
Reported error / symptom: Two images display as broken. Support observed 404 responses from their Optimole delivery URLs and original uploads URLs.
Impact: Published article content contains two unavailable images.
Reproduction notes
Reported sequence and status:
Repository confirmation: the current rollback flow can continue page processing after cloud lookup or download failure leaves the local file unrestored. No isolated runtime reproduction was performed. Missing evidence includes the installed version, transfer status, rollback logs, and attachment metadata.
Diagnosis
Conclusion
The current rollback path contains a definite state-consistency defect matching the reported dual-404 symptom. Offloading removes the local files, while multiple transfer-back failures record an attachment error and skip restoration. For page-associated rollback work, the caller then updates the page regardless of restoration success. This can advance page state or persist an origin reference while the local file is still absent. Version 4.2.10 added retries for attachment errors, but the inspected flow still does not couple page advancement to successful restoration.
Where this likely occurs
Optimole > Settings > Image Storage, duringTransfer back from Optimole Cloud, followed by image rendering on published content.inc/media_offload.php—Optml_Media_Offload::rollback_and_update_images()lines 840–904: cloud lookup or download failures setoptimole_rollback_errorand continue without restoring the local file.inc/media_offload.php—Optml_Media_Offload::start_processing_images()lines 2057–2066:update_page()runs afterrollback_and_update_images()without using its success result.tests/test-media.php—Test_Media::test_image_processed()lines 297–316: the normal offload test confirms the local attached file is removed.tests/test-media.php—Test_Media::test_rollback_retry_clears_errors()lines 360–393: 4.2.10 coverage confirms retry eligibility for failed attachments, but not page state or references after failure.40ec3aa4introduced clearing rollback errors on retry and shipped inv4.2.10;060fd3feis the 4.2.10 release commit. The unconditional page update predates that release and remains in the inspected tag.Engineering notes
The same account previously reported broken thumbnails and dual 404s after enabling cloud-only storage on Optimole 4.2.9. That prior report led to the retry work tracked in closed issue
Codeinwp/optimole-wp#1090. Current source retries attachments marked with rollback errors, but page processing and attachment restoration remain separate state transitions. This report concerns two residual images after that earlier incident; whether the site's transfer-back operation completed is unknown. Cache or page-builder involvement was not established and is not required for the confirmed control-flow defect.Test coverage status
Happy-path offload and restoration coverage exists in
tests/test-media.php, includingTest_Media::test_image_processed(),Test_Media::test_image_sync(), andTest_Media::test_image_rollback()at lines 297–358.Test_Media::test_rollback_retry_clears_errors()at lines 360–393 covers re-querying failed attachments. No relevant coverage was found during inspection for a download or sideload failure followed by page processing, persisted page references after a failed restoration, or completion state with unresolved rollback errors.What to verify or explore next
rollback_and_update_images()andstart_processing_images().Unknowns / follow-up
The current installed plugin version, transfer completion status, exact failing delivery URLs, attachment metadata, rollback logs, and page-builder storage location are unavailable. The screenshot confirms broken elements but does not expose network details. Customer-site access was not used.
Confidence
Confidence: 86/100
The missing logs control matches documented operation-scoped behavior, but the dual-404 image failure aligns with a definite rollback control-flow defect in the current plugin and with the same account's earlier offload/restore incident. Version 4.2.10 retries failed attachments, yet the inspected page-processing path can still advance after restoration failure.
Source: HelpScout #3401282656
Generated by bug-report-triage (ID: bug-report-triage_6a6988e6f0ed29.96483252)