Error getting form forwarding urls. Form not saved.

[Anonymous]

I was able to replicate this error several times by going through the following steps:

1. Open page with Marketo form as a cookied Marketo lead.

2. Delete lead in Marketo

3. Attempt to submit form (greeted with the following error)

in console:

body of response from Marketo (the decoded JSON)

4. If I refresh the page once and try again, it works fine.

However, if I switch steps 1 & 2 the error does not occur. In other words, it only occurs if the page with the Marketo form is loaded before the lead is deleted in Marketo. I'm not sure why this is. The form cannot be submitted even after waiting a few minutes; the page must be refreshed so I'm guessing it has something to do with forms2.js adding some Javascript state that has to be flushed.

Hope this is helpful to your dev team as they're debugging. Just load a form, delete the lead associated with cookie on the page you just loaded, and then try to submit the form. I highly doubt this happens often to actual leads, but it'd probably be good to understand what's going on.

Thanks!

[Brian_Litzinger]

I too am seeing this error, but we're not using the embedded form. We're using a custom form posting to the leadCapture/save2 endpoint via Guzzle. The "Error getting form forwarding urls" part of the error message is vague and abstract and could be interpreted as an error from our server, however, the "Form not saved" part of the error is clearly an error message from the Marketo endpoint. Our server and script does not know if a form is saved or not. This does not happen every time, and happens across several different server instances in our environment. Some more detailed information about the error from Marketo would be nice to have here instead of this vague, undocumented error.

[SanfordWhiteman]

Are you going over the rate limit of 1 form post every 2 seconds? (This limit is per source IP so when you attempt a server-side form post you are severely lowering your capacity.  The Forms 2.0 client-side API should be used instead.)

BTW this issue, as Micah encountered it, doesn't have to do with client-stored state exactly. It's that the garbage collector doesn't run on the server until the first "mismatched post" occurs. It's reasonable IMO that a post with a broken cookie (that is, a now-deleted cookie that was associated with a now-deleted lead) should not be serviced. in the absence of any other direction.

If you want to delete a lead and ensure that a cookie in a current pageview isn't broken, you should reassociate the cookie with a dummy lead on the server, then delete the lead.  Then the cookie will still exist, even though the original lead doesn't.