getGzipReportDownloadUrl() returning empty reports

[Zweitze]

Hi all,

Quite often, getGzipDownloadUrl() returns a URL, pointing to a 20 byte
file. When uncompressing that file, you get a file of 0 bytes.

This happens about once in every 200 reports or so, but now it just
got up a notch - I had four this morning. It happens so often I even
started to log the requestId of the getGzipDownloadUrl() call that
delivered the link to the empty report. The results of this morning
were:

Report: 608112755. RequestId: a60a7ec4aae2d6bec0d0eee98fc6f6a1.
Report: 586881504. RequestId: 4d7418cd026678190120bd16e9ea0819.
Report: 622048735. RequestId: 205436fc0d6fa04be5e209987f43bf7d.
Report: 527545241. RequestId: 0e8f982e41440161ffe0e1c62fc38368.

(The last two were only 2 minutes apart!)

A couple of days ago I experienced something different: the result of
getGzipDownloadUrl() pointed to a non existing URL (404).
Report: 1307454470. RequestId: 16f1bd53ae240b09efaf12d7b3367e32.

Note on the Report IDs: I have some cleaning up code in action,
calling deleteReport() when the code is done with the report. I hope
you can still find clues.

I wonder what I can do to prevent this from happening. Wait a while
before calling getGzipDownloadUrl() ? Call getGzipDownloadUrl() again
and try again with that result (assuming I get different URLs?). Or
reschedule that report?


Thanks in advance.

[AdWords API Advisor]

Hello,

I've investigated this behavior in the past and collected a decent
amount of debugging information. (The fact that your reports are now
deleted would make it more difficult to go through the debugging
steps, but that's okay.) Unfortunately, we've yet to come up with any
conclusive causes for either empty reports or 404 URLs (which appear
to be two distinct issues). If you get to the level of reproducibility
where we can schedule some reports at a specific time that some of the
engineering team is looking at the backend then that would be useful,
but as it is it doesn't sound like it happens often enough.

Based on what's worked for other developers, when you encounter
either issue you should be able to call getGzipDownloadUrl() using the
same report ID (assuming you haven't deleted it and that it hasn't
been bumped from the 15 report queue) and get a new download URL that
should give you the full report.

Cheers,
-Jeff Posnick, AdWords API Team

[michael s]

Hi Jeff,

We've been seeing zero-byte reports consistently for the past 7 days
between 4:50AM and 5:00AM EST. We're using getReportDownloadUrl

Here is the report ID from this morning's attempt:
551236488


- Michael

On Jan 5, 2:57 pm, AdWords API Advisor <adwordsapiadvi...@google.com>
wrote:

> > Thanks in advance.- Hide quoted text -
>
> - Show quoted text -

[Zweitze]

Jeff,

Thanks for your answer. I'll do the rewrite to retrieve a new URL in
case of an error. But it's quite a rewrite so it'll take some time.

With respect to your question about the time: Most reports are
scheduled between 5.30h and 6.00h (European time, GMT-1). In that
interval between 30 and 100 reports are scheduled. Recent errors:

10th Jan: 6.03h Empty report
11th Jan: 5.41h Empty report
12th Jan: 5.44h Empty report
13th Jan: 5.50h 404 Not Found

If you'll need repport IDs and RequestIds of getGzipDownloadUrl() let
me know. Unfortunately the code is still deleting reports it doesn't
need anymore.



On Jan 5, 8:57 pm, AdWords API Advisor <adwordsapiadvi...@google.com>
wrote:

[AdWords API Advisor]

Hello,

I'm waiting to hear back from the engineer who's assigned to this
issue as to what specific information he'd need to debug things in the
Production environment. The fact that you're deleting the reports
after an attempted download sounds like it would complicate debugging,
but I'll let you know.

Cheers,
-Jeff Posnick, AdWords API Team

[tozor]

I wanted to report an occurrence this morning, and more importantly
the fact that my workaround strategy was successful. Basically here
is what I am doing:

1) Download the file from the URL which is returned from
getGzipReportDownloadUrl()
2) Check the file size. If it is 30 bytes or less, then proceed back
to step #1

So it does not seem necessary to call getGzipReportDownloadUrl() again
to get a different download URL. In my case the same download URL
returned the full file on the second try. In all my failure cases the
size of the file returned is 20 bytes. I chose 30 bytes because
having a slightly higher limit made me feel better. All of my reports
are way larger than 30 bytes.

Hope this helps.

Tim

On Jan 13, 11:17 am, AdWords API Advisor