Interrupted image rollback can create repeated filename suffixes and stale references

[pirate-bot]

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:

1. Transfer images between the WordPress site and Optimole Cloud.
2. Run transfer-back or rollback, with at least one attempt apparently interrupted or repeated.
3. Inspect an image whose earlier stored filename ends in .1.webp.
4. Observe a local .1-1.webp file while WordPress or page content references an earlier filename.
5. 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)

[milicavs]

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.