Elementor 4.2 expands Atomic Forms workflows including secondary email behavior. When a form attachment is stored temporarily and primary and Email 2 delivery happen on different requests or queue attempts, cleanup can delete the file before the second message attaches it. A retry can also duplicate a successful recipient while recovering the failed one.
Use this for Elementor forms with file upload fields, primary and secondary email actions, asynchronous delivery, CRM actions, object storage, or custom cleanup jobs.
Quick answer
Assign every uploaded file a synthetic submission ID, immutable file ID, checksum, allowed recipient set, expiry, and required consumer list. Give each email action an idempotency key and lease the file until every required consumer is sent, permanently failed, or explicitly abandoned. Test primary success plus secondary delay, secondary failure plus retry, worker crash, cleanup race, object-storage delay, rejected file, and privacy deletion.
What to check first
- Record Elementor, form, email action, mailer, queue, storage, cleanup, PHP, and upload-policy versions and settings.
- Create allowed, oversized, rejected, multi-file, duplicate-name, Unicode-name, object-storage, and privacy-deletion fixtures.
- Trace submission ID, file ID, checksum, temporary path, durable key, consumer list, message IDs, attempts, lease expiry, and cleanup result.
- Test primary and Email 2 in every success, delay, temporary failure, permanent failure, crash, retry, and cleanup ordering.
- Prove idempotency per recipient and release the file only after all approved consumers reach terminal state.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create stable submission, file, consumer, and message identities. | Record Elementor, form, email action, mailer, queue, storage, cleanup, PHP, and upload-policy versions and settings. | Primary and Email 2 receive the exact approved file once. |
| Move queued attachments to durable approved storage before request cleanup. | Create allowed, oversized, rejected, multi-file, duplicate-name, Unicode-name, object-storage, and privacy-deletion fixtures. | Temporary failures and crashes do not duplicate successful recipients. |
| Lease each file until every required consumer reaches terminal state. | Trace submission ID, file ID, checksum, temporary path, durable key, consumer list, message IDs, attempts, lease expiry, and cleanup result. | Cleanup cannot remove a file while an active consumer lease exists. |
| Retry one failed consumer with its own idempotency key. | Test primary and Email 2 in every success, delay, temporary failure, permanent failure, crash, retry, and cleanup ordering. | Expired leases, permanent failures, retention, and privacy deletion have owners. |
Why this usually happens
- Upload cleanup and mail delivery can run on separate clocks.
- A temporary path may exist for the request but not the queued worker.
- Whole-submission retries can repeat recipients that already succeeded.
- Object storage can become durable after the queue first checks it.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
submission,file,consumer,attempt,provider_id,lease_until,state,cleanup,result
S81,F9,primary,1,M101,14:30,sent,hold,pass
S81,F9,email2,1,none,14:30,retry,hold,pass
S81,F9,email2,2,M102,14:30,sent,release,pass
S82,F10,email2,3,none,15:00,failed,review,pass
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Primary sent | Email 2 delayed | File remains leased |
| Email 2 retry | Primary already sent | Secondary sends once |
| Worker crash | After provider accept, before ack | Message ID prevents duplicate |
| Lease expiry | Consumer permanently failed | Owner alert then cleanup |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Create stable submission, file, consumer, and message identities.
- Move queued attachments to durable approved storage before request cleanup.
- Lease each file until every required consumer reaches terminal state.
- Retry one failed consumer with its own idempotency key.
- Alert on expired leases and verify privacy deletion after release.
Decision rule
Delete an attachment only when every approved consumer has a terminal state and the retention policy permits deletion. Retry only the failed consumer, never the whole recipient set.
Production verification checklist
- Primary and Email 2 receive the exact approved file once.
- Temporary failures and crashes do not duplicate successful recipients.
- Cleanup cannot remove a file while an active consumer lease exists.
- Expired leases, permanent failures, retention, and privacy deletion have owners.
Field notes
- Use harmless synthetic files with known checksums.
- Never put attachment content in shared logs.
- Set retention from business and privacy policy, not worker convenience.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache changes, and schema work on staging first.
What evidence should the report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, addresses, and private infrastructure details.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful screen as proof that background jobs, APIs, caches, roles, reports, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure paths real users have.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix an Elementor form email issue.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references