Interrupted image rollback can create repeated filename suffixes and stale references

Summary

During transfer-back from Optimole Cloud, an interrupted or overlapping rollback can leave a restored image under a collision-derived filename. A later attempt can create another suffixed filename while the attachment or content still references an earlier name. The rollback is expected to restore one consistent local filename and keep WordPress references aligned. Instead, affected images return broken URLs on the front end, and repeated attempts can worsen the filename divergence.

Customer context

Product / area: Optimole Pro image storage transfer-back / rollback
Version: Optimole version unknown
Environment: WordPress 7.1; PHP 8.1.34
Integration / third party: Hosting filesystem and WordPress media sideload workflow
Reported error / symptom: A backed-up image had a .1.webp suffix; the current local copy has a .1-1.webp suffix while stored references use an earlier filename.
Impact: Front-end images are broken on a live business site.

Reproduction notes

Reported workflow:

Transfer images between the WordPress site and Optimole Cloud.
Run transfer-back or rollback, with at least one attempt apparently interrupted or repeated.
Inspect an image whose earlier stored filename ends in .1.webp.
Observe a local .1-1.webp file while WordPress or page content references an earlier filename.
Load the affected front-end content and observe a broken image.

The exact sequence was not independently reproduced. Missing details include the Optimole version, transfer logs, pre-existing destination files, and whether individual and bulk operations overlapped.

Diagnosis

Conclusion

The rollback path is non-transactional. It moves the downloaded file into uploads before updating the attachment’s stored path. If execution stops in that interval, the moved file remains while database references retain the prior name. A retry requests the same basename and can encounter the orphaned file, allowing another collision suffix. The customer’s observed .1-1.webp file plus stale references matches this reachable failure state. The exact source of the first .1 suffix was not established.

Where this likely occurs

User-visible surface: Optimole Image Storage transfer-back / rollback.
inc/media_offload.php — Optml_Media_Offload::rollback_and_update_images() lines 864–979 derives a basename from attachment metadata, downloads the cloud image, and passes that name to wp_handle_sideload().
inc/media_offload.php — Optml_Media_Offload::rollback_and_update_images() lines 960–1004 moves the file at line 961, then performs image processing before updating _wp_attached_file at line 1004. Several early-return branches after the move do not remove the moved file.
inc/media_offload.php — Optml_Media_Offload::acquire_transfer_lock() lines 1999–2016 uses separate transient read and write operations, so acquisition is not atomic under a concurrent race.
inc/media_offload.php — Optml_Media_Offload::move_single_image() lines 2072–2105 invokes attachment processing without acquiring the bulk transfer lock, leaving an individual rollback able to overlap bulk processing.
Git history shows prior fixes in this subsystem, including rollback destination handling in 3e2d769dc57d1b29fb5e26cce4e8660ea1ae7413, attached-file updates in e725f747fe06dd8942fe7e7b08b0e1a1235b1d37, and duplicate-processing locks in the v4.2.11 line. No history evidence identifies a verified regression boundary for this behavior.

Engineering notes

The inspected plugin relies on the WordPress sideload workflow for collision naming. WordPress core source was not present in the inspected workspace, so the precise suffix algorithm was not independently verified here. The customer’s filesystem evidence confirms that a collision-derived .1-1.webp file exists. The plugin path itself confirms that filesystem mutation precedes the final attached-file update and lacks rollback of that mutation on interruption. Bulk locking reduces sequential duplicate starts, but individual rollback bypasses that lock, and transient acquisition is a read-then-write operation. The affected Optimole version and rollback logs were unavailable, limiting attribution to one exact execution path.

Test coverage status

tests/test-media.php lines 348–358 cover a successful basic rollback. Lines 360–393 cover rollback-error retry eligibility. Lines 643–741 cover sequential lock acquisition, expiry, ownership, and duplicate scheduling. No relevant coverage was found during inspection for an existing destination filename, interruption after sideload, repeated rollback after partial filesystem mutation, actual concurrent acquisition, or individual-versus-bulk overlap.

What to verify or explore next

May be worth reproducing rollback with the intended local basename already present and recording the returned sideload path plus attachment metadata.
May be worth interrupting execution after the sideload move but before update_attached_file(), then retrying the same attachment.
If reproducible, checking the targeted tests/test-media.php suite across the customer’s installed version and current v4.2.11 may clarify version scope.
May be worth exercising simultaneous individual and bulk rollback for one attachment.
If the original rollback logs become available through sanctioned diagnostics, checking timestamps around repeated processing of the same attachment may identify the observed trigger.

Unknowns / follow-up

The customer’s installed Optimole version is unknown.
The transcript did not include a REST API base, so the shared diagnostic token could not be used; rollback and offload logs were not retrieved.
HelpScout returned no ticket images or attachments.
The mechanism that first produced the .1.webp name is unverified.

Confidence

Confidence: 88/100

Repository inspection confirms a non-transactional rollback sequence: the local file is moved before attachment metadata is updated, while interrupted attempts leave collision files in place for retries. This directly supports the reported suffix cascade and stale-reference state; the exact initial .1 naming source remains unverified.

Source: HelpScout #3436947600
Generated by bug-report-triage (ID: bug-report-triage_6a978341348899.48114182)

Additional evidence from the customer logs (ticket 3436947600)

The customer supplied offload.log and rollback.log covering roughly Dec 2024 to Jul 2026 (the logger writes no year; the sequence below is reconstructed from append order). They confirm the overlapping-process hypothesis directly:

Concurrent transfer runs are frequent, on multiple plugin versions:

May 29 (2025) rollback: three runs interleaved within ~4 minutes (starts at 03:18:34, 03:19:02, 03:20:03 with counts 634/535/535, then further starts at 03:21:12, 03:21:35, 03:22:34, 03:22:43, 03:22:44).
Oct 14 (2025) rollback: two runs started 2 seconds apart, both reporting "total count of 477".
Apr 01 (2026) offload: two starts 2 seconds apart, both count 82.
May 14 (2026) offload: six starts within two minutes, all count 32. This is a recent install, so the current acquire_transfer_lock() (non-atomic transient get then set) does not prevent it in practice.
Jun 12 (2025): a runaway loop of ~150 zero-count runs ("Started with a total count of 0") in 20 minutes.

Shared process meta corrupts run state under concurrency:

Runs that started with counts 303 and 389 both logged "Process finished with 535 items", i.e. they read another process's counters.
May 14 (2026): "Process finished with 0 items in 61788.7 minutes", a stale start timestamp from a previous run.

Likely permanent data loss for a subset:
Nine attachment IDs (23858, 24291, 24326, 24490, 25681, 25955, 26030, 26065, 26318, 28371) fail with "error getting URL" or "error downloading URL" in both the Oct 2025 and Jul 2026 rollback runs, so their cloud copies are no longer retrievable while the attachments remain flagged as offloaded. A plausible mechanism is a concurrent rollback deleting the cloud copy (delete_attachment_from_server) after one process succeeded, while the racing process had already failed and left rollback_error meta behind.

On the .1 suffix: the rollback path can only produce dash suffixes (-1) via wp_handle_sideload / wp_unique_filename. The dot-style .1 names predate the logged window and were most likely created outside the plugin (the customer restored cPanel backups alongside plugin-restored copies). The plugin's contribution is compounding them: rolling back an attachment already named name.1.webp onto a disk that already held name.1.webp produced name.1-1.webp, with _wp_attached_file updated but post content references left stale. We verified on the live site that some images are broken as a result.

Suggested hardening: make the transfer lock atomic (e.g. add_option with autoload off, or wp_cache_add semantics, rather than transient get/set), re-check the offloaded/rolled-back meta immediately before sideload so a second process skips already-processed attachments, and defer delete_attachment_from_server until the attachment meta verifiably points at the restored local file.

Another customer reported this via support.

Customers on v4.2.13 experience widespread broken images and unexpected file paths that render pages unusable, matching the stale-reference and collision behavior tracked in issue #1136. The investigation confirmed a concurrency defect in Optml_Media_Offload::acquire_transfer_lock() within inc/media_offload.php, where separate transient read and write operations allow overlapping transfer requests to bypass locking. Additionally, Optml_Media_Offload::rollback_and_update_images() can move local files before updating final attachment metadata, causing divergent filesystem paths and stored references when interrupted.

Source: automated uninstall feedback — optimole-wp, 2026-09-17
Generated by bug-report-triage (ID: bug-report-triage_6aacc587c19912.49927929)

fix: reuse the file left by an interrupted rollback instead of deleti…

🧪 QA steps and test links

When restoring an image from Optimole Cloud to the Media Library is interrupted partway, the next attempt saves it under a new -1 file name and leaves the first copy behind, so the site ends up with diverging file names and stale references. Normal use can't trigger this on demand: it needs a restore request that dies midway, or two transfers that start at the same moment. The steps simulate the crash with a Code Snippet.

Requires: a connected Optimole account with Image Storage (offload) available, and the Code Snippets plugin.

Reproduce on Optimole 4.2.17:

Optimole → Settings → Image Storage: choose Optimole Cloud only and save.
Media → Add New Media File: upload a JPEG named qa-photo.jpg (it is offloaded automatically).

Snippets → Add New: title QA crash first restore, code below, Run snippet everywhere, then Save Changes and Activate.

add_filter( 'big_image_size_threshold', function ( $threshold, $size, $file, $id ) {
	if ( false !== strpos( $_SERVER['REQUEST_URI'] ?? '', 'move_image' ) && ! get_option( 'qa_crash_' . $id ) ) {
		update_option( 'qa_crash_' . $id, 1 );
		throw new Exception( 'QA: simulated crash during restore' );
	}
	return $threshold;
}, 10, 4 );

Media → Library (list view): hover qa-photo and click Restore image to media library. The restore fails.
Reload the page and click Restore image to media library again.
Open the image's details and check File URL.

Bug: the File URL ends in qa-photo-1.jpg, and qa-photo.jpg in the same uploads folder still opens as a leftover copy.
Fixed: the File URL ends in qa-photo.jpg, and no qa-photo-1.jpg exists.

Edge cases

Restore with the snippet deactivated: the image comes back under its original name with all its sizes.
A post that shows the image, restored after the crash and retry: the front end shows the image, not a broken one.
Bulk transfer back (Image Storage → Transfer back from Optimole) of several images: all return under their original names, no -1 files.
Start the bulk transfer from two browser tabs at nearly the same moment: one transfer runs, and every image moves once.

Assumption: the crash is simulated just before the restored image's sizes are generated, which is the window the fix covers. A crash at another point may behave differently.

Fix: #1191 (open, draft; no build yet)

fix: make the transfer lock atomic and clean up files left by interru…

Navigation Menu

Repository navigation

Interrupted image rollback can create repeated filename suffixes and stale references #1136

Summary

Customer context

Reproduction notes

Diagnosis

Conclusion

Where this likely occurs

Engineering notes

Test coverage status

What to verify or explore next

Unknowns / follow-up

Confidence

🧪 QA steps and test links

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Interrupted image rollback can create repeated filename suffixes and stale references #1136

Description

Summary

Customer context

Reproduction notes

Diagnosis

Conclusion

Where this likely occurs

Engineering notes

Test coverage status

What to verify or explore next

Unknowns / follow-up

Confidence

Activity

milicavs commented on Sep 2, 2026

pirate-bot commented on Sep 18, 2026

milicavs commented on Oct 20, 2026

🧪 QA steps and test links

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions