WordPress 7.1 Beta 3 fixes a Safari HEIC duplicate-attachment path, but media offload can introduce another retry boundary after conversion. If the source object, converted image, derivatives, and attachment metadata do not share an idempotency key, a network retry can create a second row or orphan object family.
Use this for Safari and iPhone upload workflows with HEIC conversion, S3-compatible storage, CDN delivery, background optimization, forms, listings, or customer-submitted photos.
Quick answer
Assign one correlation ID to the Safari action, record its network requests, and trace the same ID through attachment insert, conversion, object writes, metadata commit, and local cleanup. Interrupt at each boundary and retry. One action must resolve to one attachment ID and one complete object family.
What to check first
- Record Safari and OS version, WordPress build, HEIC support, conversion target, image library, offload mode, object versioning, queue worker, and CDN configuration.
- Hash the HEIC fixture and record request ID, attachment ID, source object, converted object, derivatives, metadata update, and cleanup action.
- Interrupt after source upload, after conversion, during offload, after object write, and before attachment metadata commit.
- Repeat the user action and replay the background job while the first attempt is delayed to expose duplicate rows and object versions.
- Inspect Media Library, attachment metadata, local disk, bucket keys, CDN URLs, and logs for one coherent identity.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create one correlation and idempotency key | Record Safari and OS version, WordPress build, HEIC support, conversion target, image library, offload mode, object versioning, queue worker, and CDN configuration. | Network, conversion, offload, and metadata logs share one request identity. |
| Trace every conversion and offload boundary | Hash the HEIC fixture and record request ID, attachment ID, source object, converted object, derivatives, metadata update, and cleanup action. | Exactly one attachment row exists after each retry case. |
| Inject interruption and acknowledgement loss | Interrupt after source upload, after conversion, during offload, after object write, and before attachment metadata commit. | Expected object keys and versions match attachment metadata. |
| Reconcile rows, files, and object versions | Repeat the user action and replay the background job while the first attempt is delayed to expose duplicate rows and object versions. | No local or remote orphan remains after cleanup. |
Why this usually happens
- The browser request and background offload job can retry independently.
- Conversion may create a new filename before attachment identity is durable.
- An object write can succeed even when its acknowledgement is lost.
- Cleanup can remove the local source before metadata points to a durable object.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
request_id: heic-20260725-03
source_sha256: recorded
attachment_ids: [9472]
source_object: uploads/2026/07/yard.heic
converted_object: uploads/2026/07/yard.jpg
derivative_count: 4
offload_replay: true
duplicate_rows: 0
orphan_objects: 0
result: pass
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Create one correlation and idempotency key
- Trace every conversion and offload boundary
- Inject interruption and acknowledgement loss
- Reconcile rows, files, and object versions
- Replay safely and verify CDN output
Decision rule
Pass when one Safari action and all retries resolve to one attachment, one expected source and derivative family, consistent metadata, no orphan objects, and correct origin and CDN rendering.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Network, conversion, offload, and metadata logs share one request identity.
- Exactly one attachment row exists after each retry case.
- Expected object keys and versions match attachment metadata.
- No local or remote orphan remains after cleanup.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Should the original HEIC be retained?
That is a policy choice. Define the expected source and converted objects before testing, then verify retention and privacy consistently.
Can object versioning hide duplicates?
Yes. Count attachment rows, logical object keys, and object versions separately so retries are visible.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, test Safari HEIC media offload.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references