Hey there @ukrossco - thanks for sharing this! I’m sorry to see you’re coming across this error!

The only thing I can think of is perhaps is the quantity of the leads coming through resulting in the timeout? https://zapier.com/help/troubleshoot/errors/504.

Outside of that though, it might be worth hanging tight to see what our friends in support have to share! They’re able to dig into the logs and may be able to provide a bit more insight. Definitely keep us posted on your findings though!

Hi Christina

Support came back and said that this is indeed a bug and I can see that the timeout on this has been extended to try to prevent it failing.

Unfortunately, a second issue has now appeared. As the timeout has increased, the step fails but does not return to zapier a success or failure message, it just times out.  I’m guessing that the actual Send Offline Conversion remains in a queue somewhere in the backend and is eventually successful. 

This sounds great, but it introduces a second more serious problem: Zapier sees the timeout as a failure and reschedules the step which would seem the sensible thing to do.  In the time between this failure and the reschedule run time, it seems the ‘Send Offline Conversions’ step is actually successful having been queued somewhere outside of the zap runtime. This means that when the rescheduled step runs, the step returns an error of ‘gclid/timestamp already exists’ and zapier reschedules the step again. 

The problem is that once this duplicate gclid/timestamp error has been returned from the step, it will always return this error which will always result in the step being rescheduled. The result being that the ‘Send Offline Conversions’ step becomes an infinite loop of reschedule/error/reschedule and these loops need to be killed off manually in the ‘Zap Runs’ screen. Because the loop occurs within a single step, there is no way to handle the failure.

My suggestion would be that the duplicate gclid/timestamp error is reclassified as a warning or advice and assigned as an output to the step in order that the step can proceed and this situation can be handled by subsequent steps in a zap rather than forming an infinite loop.  Sometimes when dealing with complex marketing scenarious, duplicate gclid/timestamps do occur and I would say that the detection of these is a success rather than a failure of the step.  After all, it has done its job rather than failed outright. Much in the same way that when searching for spreadsheet rows, the step can still be considered a success even if none are returned.

I think it’s also worth noting, that last week the step was taking 20 - 60s to return a successful ‘Send Offline Conversions’.  This week it is taking in excess of 180s and I wonder if this might be due to the additional load brought about by this reschedule/error/reschedule loop where duplicate gclid/timestamps exist (and particularly since they now appear to be being actioned even after this step has timed out).

I’m in touch with Sydney in support and have emailed across my suggestions - hopefully we can get this fixed ;-)

Many thanks

Ross

Hey @ukrossco! Thanks for letting us know. I caught up on your thread with support and do see the related bug for this. We’ll make a note that this thread is related and post any updates we have on that specific bug here as well, for anyone else following along.

In the meantime, I wanted to share this helpful workaround from @cschimoler:

As for your second question/feedback, I want to first thank you for taking the time for writing such thoughtful suggestions. It’s certainly helpful for our product team to consider when making changes to the functionality of our platform.

I noticed you shared some of this feedback on your email thread with support, who replied to you and said:

Thanks for following up and providing this additional insight! 
 
I will say, the Zap will never get caught in an infinite loop of retrying errored Zap runs. Zapier backs off after each successive failed retry attempt, on this schedule:

• 5 minutes
• 30 minutes
• 1 hour
• 3 hours
• 6 hours

This means that if the Zap run errors at 1:00 p.m., Autoreplay will try again at 1:05, 1:35, 2:35, 5:35, and 11:35. The back-off schedule implies the final retry happens approximately 10 hours, 35 minutes after the first error. Although this isn't an infinite loop of retrying the error, it does cause any actions that depend on the steps output to not run as expected. 
 
In regard to the Zap interpreting the duplicate glcid/timestamp error, I can see how it would be valuable to continue on in the Zap given the bug that causes the error. However, this isn't exactly the same as a Zap Halting and being able to continue when we do not Find a record. In this case though, we get an error when trying to create a record, and albeit because of a bug, it is still expected behavior that the Zap would error in this case. 

If you have any other feedback/questions about this, continuing to follow-up on that support thread is going to be your best way forward. 🙂

Hello - 

It seems this error has entirely broken the Google Ads integration with offline conversions. 

I am unable to successfully create / send any new zaps involving offline conversions with Google Ads. 

The 504 error occurs every time when trying to complete the offline conversion in testing. Which locks the zap into a draft and does not allow me to publish.

Even when I duplicate zaps that are successfully submitting offline conversions to Adwords - The steps are identical, yet the old zap successfully passes & the new zap fails. 

This is completely halting our marketing efforts - I cant find a definitive solution to this anywhere. 

Any help would be amazing!

After some trial and error I have been able to work around this issue, if you work from Google Ads to Zapier it seems to cooperate. 

I had success by creating new conversion events in google ads and continuing to zapier through the hubspot integration there. 

Not sure what difference it made or why it would change anything but I have have been able to replicate several successful offline conversion events with this approach. 

@cschimoler Oh this is wonderful news! I will update the best answer here with your workaround. Thank you for coming back into this thread to share and help others! 🙌

@ukrossco Did you manage to find a way around this yet at all?

I’ve seen @cschimoler ‘s suggestion, but as we’re not using Hubspot I don’t think this will work for us.

Next optoon is to call a Python code step, but keen to avoid that if at all possible.

I’m running into this issue, albeit adding Klaviyo Profiles to Google Ads Customer Match Lists via email.

The setup on the Google Ads side links you to Zapier when you select that option, and testing worked originally. Out of 15 emails attempted to be added, only 5 have been successful. The data size should be the same for each request - it’s just email.

This is really disappointing considering both Zapier and Google are promoting this integration as available, but seems like it is at best inconsistent and at worst, unusable.

Hi @ross.hopkins, I’m really sorry that you’re having this trouble with your Google Ads step. 

The team that handles this app is looking into the issue and I’ve added you as an affected user on the bug report, which means that we’ll send you an email when there’s an update. In the meantime, I can only apologize that the integration isn’t working the way that it should. 

I have this same issue. Timeout error when attempting to test the action.

@Danvers Somewhat related to this thread: Are there any plans to implement the “Send Call Conversions Google Ads”? (Currently you support Click Conversions via GCLID and Enhanced Conversions via Phone or Email, but you do not support Call Conversions via Phone (different than Enhanced Conversions)).

Best,

Alex

Hi @aczarto 

I’ve added you to the list of affected users. We’ll update you via email once an update is available.

I have this same issue. Please fix it as soon as possible! Thanks

@jammer.solijon same problem here, constantly 180 sec timeout error on google ads offline conversions… can we get an ETA when this is fixed?

Hi There,

My offline conversions back into Google Ads keep timing out.  Is there anyway to fix this?

Failed to create an offline conversion in Google Ads

<html> <head><title>504 Gateway Time-out</title></head> <body> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx</center> </body> </html> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page -->

show more

Hi kpidan, MISCH, and Ro Ahuja,

I’ve added you guys to the list of the affected user, and we’ll update you via email once this fix is implemented. Thank you, Matthew.Harris, for this awesome workaround. Kindly try this temporary fix that he mentioned and let us know if that works. 

Wow, @Matthew.Harris! 🤩This really is incredible!

We can’t thank you enough for sharing this with the Community.

Hi @jammer.solijon Could you please add me as well? Same issue here.

Hey @Tim-saas.group 

I'm sorry to learn that you are also encountering the same issue. I've added you to affected users, and we'll update you via email once available. Thanks!

Have the same issue, could I please also be added?

Hi @AT JumpStory 

I’ve added you to the list of affected users and we’ll email you an update once available. Thank you!