Spam retention may remove a Gravity Forms entry while its uploaded file remains in a custom directory, Media Library, object storage, backup, thumbnail cache, malware scanner, notification attachment, or add-on table. The opposite error can delete a file still referenced by a valid entry.
Use this for application, support, insurance, legal, healthcare, recruitment, membership, and ecommerce forms that accept files and automatically retain or delete spam submissions.
Quick answer
Seed synthetic spam and valid entries with uniquely marked files in every configured storage path. Run the scheduled retention action, retry it, and compare the database, local disk, object storage, CDN, logs, backups, and downstream systems against a documented retention matrix.
What to check first
- Inventory active, spam, trash, draft, partial-entry, notification, local upload, Media Library, custom path, offload, CDN, scanner, backup, log, and add-on locations.
- Create synthetic files with safe contents, unique hashes, matching entry IDs, and expected deletion dates for spam plus valid control entries.
- Run the retention event normally, after a missed cron schedule, in a small batch, and after terminating a worker between entry and file deletion.
- Replay the same batch to prove idempotency and test shared files, duplicate names, missing files, permission errors, and offload API failures.
- Document backup expiry, legal holds, privacy requests, deletion evidence, failure alerts, owner, and recovery procedure.
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 |
|---|
| Map every file data location | Inventory active, spam, trash, draft, partial-entry, notification, local upload, Media Library, custom path, offload, CDN, scanner, backup, log, and add-on locations. | Every due synthetic spam file has the expected local and remote outcome. |
| Seed spam and valid controls | Create synthetic files with safe contents, unique hashes, matching entry IDs, and expected deletion dates for spam plus valid control entries. | Valid entry files remain reachable and unchanged. |
| Run normal and interrupted deletion | Run the retention event normally, after a missed cron schedule, in a small batch, and after terminating a worker between entry and file deletion. | A repeated deletion run creates no error or unrelated deletion. |
| Retry and inspect orphan detection | Replay the same batch to prove idempotency and test shared files, duplicate names, missing files, permission errors, and offload API failures. | Backup expiry and external copies have named owners and documented dates. |
Why this usually happens
- Entry and file deletion can occur in separate operations without one transaction.
- Offload plugins may replace local paths with remote object references.
- Notification or scanner workflows can copy the file elsewhere.
- A failed cron action can delete the entry but stop before remote cleanup.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
entry_id: 77420
status: spam
retention_due: 2026-07-26
file_hash: sha256:test-only
local_file: deleted
object_copy: deleted
cdn_status: 404
backup_expiry: 2026-08-30
retry_result: no_change
valid_control_file: present
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.
- Map every file data location
- Seed spam and valid controls
- Run normal and interrupted deletion
- Retry and inspect orphan detection
- Record backup and privacy outcomes
Decision rule
Pass when due spam entries and their owned files are removed or retained under a documented exception, valid controls remain intact, retries are harmless, failures alert an owner, and remote plus backup outcomes are recorded.
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
- Every due synthetic spam file has the expected local and remote outcome.
- Valid entry files remain reachable and unchanged.
- A repeated deletion run creates no error or unrelated deletion.
- Backup expiry and external copies have named owners and documented dates.
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, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Does deleting a Gravity Forms entry always delete its uploaded file?
Do not assume it does for custom paths, offload storage, notifications, add-ons, or backups. Test each configured location.
Should backups be altered for each deletion request?
Backup handling depends on policy and legal requirements. Common controls include restricted access, defined expiry, and preventing restored data from silently re-entering production.
When HandL WP should help
Bring in HandL WP when a production checkout, form, email, media pipeline, code-quality gate, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, audit Gravity Forms file retention.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references