Symptom: an attempt didn’t create a child entry, and the series shows an issue or has stopped.
The Recovery Loop #
- Read the outcome in Queue’s Last attempt / result column.
- Open attempt history for the detail, including any validation field IDs.
- Fix the cause — usually on the form or in the parent entry’s data.
- Click Retry Failed Submission. A success resolves the issue and resets the consecutive count.
- If the series stopped, Retry or Resume reopens automatic attempts.
How Failures Escalate #
| Step | What happens |
|---|---|
| First failure | Creates a current issue; an alert goes to the Admin Email; a Failed Resubmission notification fires |
| Further failures | The consecutive count rises. Automatic retries continue |
| Threshold reached (3 by default) | The series becomes failed and automatic attempts stop |
| A success | Resolves the issue and resets the count. Earlier attempts stay in history |
A series can be scheduled and need attention: the issue is open, but the next automatic retry is still on the calendar.
The threshold is configurable globally, and can be overridden per feed.
Validation Failures #
The most common cause by far.
Attempt history lists the field IDs that failed validation — never the values, because values can carry personal data.
| Cause | Fix |
|---|---|
| A required field is empty | Ensure the value is saved on the parent, or make the field optional |
| A Dynamic lookup returned blank for a required field | See Values Are Wrong or Empty |
| A date update produced an invalid value | Check which fields are selected under Update Date Field(s) |
| Form validation was tightened after the series started | Either relax it, or update the parent entry |
| A field was deleted from the form | Update the form or the feed |
Automation is not exempt from validation. A child submission goes through the same Gravity Forms validation as a human one.
Exceptions #
An exception records the safe class and code, plus the attempt ID in the Gravity Forms add-on log.
Exception messages are excluded deliberately — they can contain personal data or tokens.
What to do: enable logging at Forms → Settings → Logging, reproduce with Retry, and send the log excerpt plus Copy Diagnostics to support.
Storage Failures Are Different #
A storage failure means a child entry may have been created before its operational records could be saved. It is not a rejected submission.
The plugin therefore:
| Behaviour | Reason |
|---|---|
| Reports the known child entry ID | So you can verify what happened |
| Blocks further submissions | So a blind retry can’t duplicate a real entry |
| Keeps Cancel available | Cancelling never deletes children |
| Labels older unfinished attempts as requiring review | They aren’t proof that nothing was submitted |
What to do:
- Open the named child entry. Does it exist and look complete?
- Check attempt history for interrupted attempts.
- Decide whether the occurrence really happened.
- Only then proceed.
Repairing the database schema does not clear this state.
After a Network Interruption #
If your browser lost the connection mid-action, check Queue and attempt history before retrying. The server may have completed the submission.
Every action reports its real result — attempt ID, outcome, child ID, next target — so the record is authoritative even when your browser never saw it.
What Never Counts as a Failure #
| Event | Counts as a failure? |
|---|---|
| Conditional skip | No |
| Skipped missed run | No |
| Late but successful attempt | No |
| Successful attempt | No — it resets the count |
If the counter isn’t moving the way you expect, check whether you’re actually looking at skips.
Retry vs. Resume #
| Action | What it does |
|---|---|
| Retry Failed Submission | Submits the failed target now. A success resolves the issue. |
| Resume | Reopens automatic attempts at the next eligible future slot, without submitting now. |
Use Retry when you want proof the fix worked. Use Resume when you’re confident and content to wait for the next scheduled run.
The old Mark as Fixed action is gone. It removed history and counted an unverified submission as successful. The plugin now requires an actual success to close an issue.
