Interrupted image rollback can create repeated filename suffixes and stale references

Empieza con Optml_Media_Offload::rollback_and_update_images() y sus rutas de movimiento de archivos y actualización de archivos adjuntos en inc/media_offload.php; después inspecciona acquire_transfer_lock() y move_single_image(). Ejecuta las pruebas relevantes de tests/test-media.php, especialmente las secciones de rollback y locks. Done debe cubrir rollback interrumpido o repetido, archivos de destino existentes y la superposición entre las operaciones individuales y masivas, sin referencias obsoletas ni divergencias repetidas de sufijos.

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)