Re: api version 201605 - batchjobservice

t;>>>> Hi Josh, >>>>> >>>>> Thank you for your help, as for this particular operation, the job is >>>>> no longer valid (our side), because the subsequent pushes will have >>>>> invalidated/overwritten it. It is of vital

Re: api version 201605 - batchjobservice

e >>>> invalidated/overwritten it. It is of vital importance, the underlying >>>> issue (api side) is addressed asap, by the time the issue is resolved that >>>> job is no longer valid. >>>> >>>> Now, that we have the sunset on api v201601 appr

Re: api version 201605 - batchjobservice

;> issue (api side) is addressed asap, by the time the issue is resolved that >>> job is no longer valid. >>> >>> Now, that we have the sunset on api v201601 approaching fast, we are on >>> v201605, can't rollback. The problem in this thread as well as this api

Re: api version 201605 - batchjobservice

e sunset on api v201601 approaching fast, we are on >> v201605, can't rollback. The problem in this thread as well as this api >> version 201605 >> <https://groups.google.com/forum/#!topic/adwords-api/tJ0kMpEvjJM>, tells >> us the batchjobservice is not 100% relia

Re: api version 201605 - batchjobservice

resolved that > job is no longer valid. > > Now, that we have the sunset on api v201601 approaching fast, we are on > v201605, can't rollback. The problem in this thread as well as this api > version 201605 > <https://groups.google.com/forum/#!topic/adwords-api/tJ0kMpEvjJM>

Re: api version 201605 - batchjobservice

that job is no longer valid. Now, that we have the sunset on api v201601 approaching fast, we are on v201605, can't rollback. The problem in this thread as well as this api version 201605 <https://groups.google.com/forum/#!topic/adwords-api/tJ0kMpEvjJM>, tells us the batchjobservice is n

Re: api version 201605 - batchjobservice

Hi Zia, The *downloadUrl* has been regenerated for that job. Please get the *downloadUrl* from *BatchJobService* again and try to download results. Thanks, Josh, AdWords API Team On Tuesday, August 23, 2016 at 9:40:16 AM UTC-4, Josh Radcliff (AdWords API Team) wrote: > > Hi Zia, > > I just

Re: api version 201605 - batchjobservice

Hi Zia, I just asked for an update on that job. I'll reply back here as soon as I have more information. Thanks, Josh, AdWords API Team On Tuesday, August 23, 2016 at 6:32:11 AM UTC-4, xtcsuk wrote: > > Hi Thanet, > > Any luck with this issue, as instructed, posted the requested info a few >

Re: api version 201605 - batchjobservice

Hi Thanet, Any luck with this issue, as instructed, posted the requested info a few days ago, hope you have got it. regards, Zia On Thursday, 18 August 2016 03:59:53 UTC+1, Thanet Knack Praneenararat (AdWords API Team) wrote: > > Hello Zia, > > I'll handle this case instead of Josh. > It's

Re: api version 201605 - batchjobservice

Hello Zia, I'll handle this case instead of Josh. It's fine to post in this thread again, but would be more easy for you to track the answers if you create another thread instead. For this case, could you please pass me your download URL as well using *Reply privately to author*? I saw some of

Re: api version 201605 - batchjobservice

Hey Josh, Its me again, this time a different issue, was not sure to create a new thread, so here it goes: The job: job id account id 344573194 1011654677 has a "CANCELLED" status with a downloadUrl assigned to it, but on get the results, it throws 404, may be

Re: api version 201605 - batchjobservice

Hi Josh, Thank you for the clarification, on our side, however, as you can imagine, we have logic to compare the two (upload/result) to marry up the operation results. So, if the numbers do not match, it just simply don't work. Firstly, hoping for this not happen again (permanent fix), will

Re: api version 201605 - batchjobservice

Hi Zia, The count mismatch is an artifact of the failed download URL generation. You can safely ignore the mismatch (in this particular case) when processing the results from the URL. Thanks, Josh, AdWords API Team On Monday, August 15, 2016 at 11:39:45 AM UTC-4, Josh Radcliff (AdWords API

Re: api version 201605

>> >>> I have reopened the other thread for us to track that issue separately, >>> and we will be responding there once we've had a chance to look into it. >>> >>> Regards, >>> Mike, AdWords API Team >>> >>> On Friday, August 12, 2016 at

Re: api version 201605

>> Regards, >> Mike, AdWords API Team >> >> On Friday, August 12, 2016 at 5:42:25 AM UTC-4, xtcsuk wrote: >>> >>> Thank you Mike, >>> >>> I posted another issue on the 11th of August titled "api version 201605 >>> - batchjob

Re: api version 201605 - batchjobservice

Hi Zia, I'm looking into that one and will get back to you with an update. Thanks, Josh, AdWords API Team On Monday, August 15, 2016 at 9:08:56 AM UTC-4, xtcsuk wrote: > > Hi Josh, > > Thanks again, sorry my mistake. > > On this subject, this is a job details where we have a discrepancy in >

Re: api version 201605 - batchjobservice

Hi Josh, Thanks again, sorry my mistake. On this subject, this is a job details where we have a discrepancy in between the number of operations uploaded and number of operations executed: job idaccount id 342115475 7653799969 our application is limited to assign maximum

Re: api version 201605 - batchjobservice

Hi Zia, The job I was referring to was batch job ID 341175452, which had status of CANCELED (please see your first email on this post). The current status remains as CANCELED. 341175452 CANCELED 2 2 66

Re: api version 201605 - batchjobservice

Hi Josh, Thank you for your reply, The job in question did originally included a downloadUrl, however the progressStats is not somewhat correct. My question is around this, why the job's progressStats.estimatedPercentExecuted is at 60% and yet BatchJobStatus is Done, I would expect

Re: api version 201605 - batchjobservice

Hi Zia, A fix was applied for that job. If you retrieve the BatchJob again, you should get back a *downloadUrl* and be able to get the results. Thanks, Josh, AdWords API Team On Friday, August 12,

Re: api version 201605

y, August 12, 2016 at 5:42:25 AM UTC-4, xtcsuk wrote: >> >> Thank you Mike, >> >> I posted another issue on the 11th of August titled "api version 201605 - >> batchjobservice", but is marked as duplicate. Can't open the thread >> anymore, its tak

Re: api version 201605 - batchjobservice

Hi Zia, Mike just pointed out that this is a different issue from the other post. I'm following up on this one and will get back to you as soon as I have more information. Thanks, Josh, AdWords API Team On Thursday, August 11, 2016 at 2:04:14 PM UTC-4, Josh Radcliff (AdWords API Team) wrote:

Re: api version 201605

, xtcsuk wrote: > > Thank you Mike, > > I posted another issue on the 11th of August titled "api version 201605 - > batchjobservice", but is marked as duplicate. Can't open the thread > anymore, its taking me here: > This is a different issue, we have downloadUrl, Done

Re: api version 201605

Thank you Mike, I posted another issue on the 11th of August titled "api version 201605 - batchjobservice", but is marked as duplicate. Can't open the thread anymore, its taking me here: This is a different issue, we have downloadUrl, Done as job status, but the stats does n

Re: api version 201605 - batchjobservice

Hi Zia, I see you already are discussing this issue with Mike on another post , so I'll mark this one a duplicate. Mike is still looking into this issue for you and will respond on the other post. Thanks, Josh, AdWords API

api version 201605 - batchjobservice

Hello, A question around a cancelled job, on getting result for a job, the data tells us the job has been cancelled, no downloadUrl and with the following stats: service call: batchjobservice.get(selector).entries api call result: estimatedPercentExecuted: 60%, numOperationsExecuted: 2,

Re: api version 201605

Hello, I will pass these IDs along to engineering so they can get the download URL to show properly. Regards, Mike, AdWords API Team On Thursday, August 11, 2016 at 8:10:54 AM UTC-4, xtcsuk wrote: > > Hi Mike, > > Thanks for the clarification, looks like the empty download url bug still >

Re: api version 201605

Hi Mike, Thanks for the clarification, looks like the empty download url bug still persists, for a handful number of jobs, at least. Here is the list (been identified so far) JobId, AccountId Approximate upload time 3410042976985053702

Re: api version 201605

Hello, The bug that caused this issue has still not been fully addressed. Engineering is hard at work on getting that in as soon as possible. This means that it is possible (but very unlikely) that a job with operations moves into a DONE status, but erroneously shows that it has no operations

Re: api version 201605

Hi Mike, Thank you, As for the old jobs, they are no longer valid, as the system has moved on with new changes. So, this has now been rectified, in case of a job with no operation, the api will throw or something on upload, and will not move the job status from pending to complete, right?

Re: api version 201605

Hello, The engineering team has confirmed that they are aware of a bug that can put jobs into this state when they shouldn't be. They do have a process they can perform on these "stuck" jobs to force them to return a correct DownloadUrl. If you provide me with a complete list of jobs that

Re: api version 201605

Hello, I apologize for the back and forth. I've contacted our engineering team to take a look at a specific job you provided and see if we can determine exactly what is going wrong from there. I'll let you know if I need more information from you or if I have any updates to share. Regards,

Re: api version 201605

Thanks again for your reply. Based on our records that particular job should have contained at least 173 operations. Our process in a nutshell, the system creates a batch, which contains >=1 jobs, this particular job was part of a batch which contained 218 jobs all of which finished with

Re: api version 201605

Hello, Under normal circumstances, the job shouldn't move to Done unless some data has been provided and processed. That's why I'm so curious about what exactly made it into your request that allowed this to happen. Regards, Mike, AdWords API Team On Friday, August 5, 2016 at 11:03:35 AM

Re: api version 201605

Hi Mike, Thanks for the reply, our records show the job included some operations, but do not have the log to provide you with, will try to see if we can do this. In the meantime, is it possible for a job change status from Active to Done with no operations attached to it? regards, Zia On

Re: api version 201605

Hello, I took a look at the log you provided. It appears that in the case where the downloadUrl is omitted, there were also no operations performed, which means there would be no results to share via the downloadUrl anyway. Do you have logs of exactly what operations you uploaded for such a

Re: api version 201605

Hi Pete, We are still suffering from batchjobservice returning null downloadUrl (intermittently) for a completed (done) job, sent you the soap (request/response) privately, just wondering if you have received it. regards, Zia On Tuesday, 2 August 2016 04:09:00 UTC+1, Peter Oliquino wrote: > >

Re: api version 201605

Hi Zia, Feel free to contact us anytime if you encounter any issues. Cheers, Peter AdWords API Team -- -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and Google+: https://googleadsdeveloper.blogspot.com/ https://plus.google.com/+GoogleAdsDevelopers/posts

Re: api version 201605

Thanks Peter, On downloadUrl property of the BatchJob entity, I was wrong in assuming it to have a value all the time, irrespective of the status (cancelled/done). So yes, thanks for clarifying that. On report sides, nothing has changed in criteria on our side, will keep an eye and will do as

Re: api version 201605

Hi Zia, Please see below my answers : 1. The report service (arbitrary report types) seems to time out more frequently than v201601. We have a retry logic in place, where these errors are retried and they eventually succeed. *One possible cause of the timeouts would be that you are

api version 201605

Hello, We have just moved to the above version, couple of issues, I would appreciate clarifications with: 1. The report service (arbitrary report types) seems to time out more frequently than v201601. We have a retry logic in place, where these errors are retried and they eventually succeed.