I am having a problem understanding the operation results from a BMJS request that has a rigged failure for testing. For the purposes of identifying failures, I have expanded on the bulkProcessResults function, included in the PHP library. I have begun passing a zero- based-indexed array of the actual operations requested. For my tests, I am submitting a total of 23 keywords, with 1 rigged to fail. Using a zero-based index, this would be operation[0] through operation[22]. The rigged operation is at operation[19].
After receiving a response, the first operation result will be a 'FailureResult', according to API documentation and past experience. Given that I have passed the actual operations array to the processing function, I am able to parse each error and reference the 'fieldPath' to figure out which operation(s) caused the atomic failure. This part is working as expected with no issues. Moving forward, since this is an "atomic" failure, and all 23 operations will fail, the remaining results in the response are of the type 'BatchFailureResult'. The problem seems to begin here. The results show the following: Results were not successful in batch index of operation: 1 [...] Results were not successful in batch index of operation: 19 Results were not successful in batch index of operation: 20 Results were not successful in batch index of operation: 21 Results were not successful in batch index of operation: 22 First, the number of batch failures(22) does not match the number of operations(23). Secondly, batch indexes 19-22 are included. Contemplating this, the reason for this may be this: If an operation is the cause of a batch failure and included in the FailureResult, then it might be omitted from the BatchFailureResult as an assumption. Secondly, these 'Results were not successful in batch index of operation: X' do not match the zero-based operations array from the request itself because if the 'FailureResult' operation is omitted, then 'Results were not successful in batch index of operation: 19' would have been omitted from the BatchFailureResult. Assuming that a FailureResult operation is omitted from the BatchFailureResult, I ran another test. This time, an additional rigged keyword failure was included. Again, a total of 23 operations were requested, operation[0] through operation[22], and the rigged failure operations are at operation[19] and operation[21]. The operations results are very much the same. The exception being an additional operationResult->cause->errors within the FailureResult. However, the BatchFailureResults are exactly the same, with 22 total batch failures and the same indexing scheme. As for why this is important to me. As explained earlier, picking the actual failure triggers from the FailureResult is working as expected. However, since the failures are atomic in nature, all other operation in the batch should be marked in some way as part of a batch that failed. This way, they can be processed during the next run, while omitting the actual trigger. Any help would be greatly appreciated. -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
