Choose the next step before retrying a lead

Synthetic demonstration · n8n 2.47.3 · local Python/SQLite destination

A lead form can look successful while its CRM update fails. Repeating every failed request adds another risk: the destination may already have saved the lead before the response was lost.

I built a small demonstration around three decisions: retry, stop, or review.

The original workflow validated incoming leads and used a general three-attempt retry setting. That proved a useful transient-failure path, but it did not distinguish permanent HTTP errors from rate limits or uncertain delivery.

The workflow now preserves the HTTP response and routes it through an explicit policy:

Stop on authentication and validation errors instead of repeating the same request.

Retry the fixture's known pre-commit temporary failure within three total attempts.

Respect a valid numeric Retry-After within the two-second demonstration budget. Missing, empty, invalid or longer values go to review.

Reuse the identical request identity only when the destination has a verified replay contract.

Stop as unknown delivery when the response is lost and safe replay cannot be established.

Review also caught two subtle defects: an empty header could become a zero-second wait, and JSON-only parsing could obscure a plain-text authentication error. Review then caught a response-field mismatch that could hide the returned identifier. The final policy requires the expected identifier and destination outcome before marking a successful HTTP response as delivered. Classifier tests cover malformed success bodies; the HTTP runs verify the valid returned identifiers.

The final run exercised eight behavior families through 19 explicit requests. A separate readiness probe was excluded from that count. The same checks passed after extracting the source package into a clean directory.

Authentication and destination-validation failures stopped after one outbound attempt. The controlled rate-limit case waited about 1.079 seconds for a one-second Retry-After. Safe replay preserved one stored record; conflicting content under the same key was rejected. Exhaustion produced one local alert.

The important check is the destination's state. In the lost-response scenario without safe replay, the local destination had already committed a lead. The workflow kept that outcome visible for review rather than treating it as proof that nothing happened.

The proof includes the workflow, fixture, request traces, engine-to-request mapping and reproduction checks. It uses a local synthetic destination. A real repair still needs the actual API's documented behavior, safe test access and an agreed acceptance check. Production authentication, concurrent load, durable recovery and external alerts are outside this demonstration.

Have one reproducible lead-delivery failure? Send the redacted failing step, expected result and n8n version through the bounded n8n repair service.