Check objects exist before creating them

error-codes
api

#1

We just ran into a situation I wanted to bring to your attention and hopefully help other developers in the future. Maybe a feature request or bug report.

Here’s the situation. We created a product feed calling a POST to the /product_feeds endpoint with the required data:

{"name":"Our Feed 20160914","url":"http:\/\/our.server.com\/files\/feeds\/example\/product_feed.tsv"}

The API replied:

{"errors":[{"code":"SERVICE_UNAVAILABLE","message":"Service unavailable due to request timeout; please try the request again later"}],"request":{"params":{}}}

A minute or two later, our job ran again, and we got another error trying to create the product feed:

{"errors":[{"code":"DUPLICATE_DETECTED","message":"A feed with the same url already exists"}],"request":{"params":{}}}

Sure enough, GET /product_feeds showed it existed.

We’ve since updated our code to check if a product feed exists calling the GET /product_feeds endpoint first, and parsing the results to see if a prior POST of ours actually succeeded. If so, we initiate upload, else try to create again.

My thoughts are that if Twitter Advertiser API replies with SERVICE_UNAVAILABLE we should be assured that our request was not honored. In this case it appears that it was, with a misleading false positive reply. It seems that in several cases we’ve received INTERNAL_ERROR from the API as well. In those cases, our objects were not created.

I’m a bit concerned now that I will need to go through all my code and check the GET endpoint and parse it before issuing POSTs to create objects, regardless of an error-like message from a prior POST.

Is this a bug, or the intended usage? I would think you’d prefer to minimize the number of required requests to implement a solution, and treat failure-type replies as transactional in nature, thereby reducing overhead on both ends. In other words, if you reply SERVICE_UNAVAILABLE to a post, in my opinion you should disregard it (delete it from your internal queues, if possible) since I naturally expected that it wasn’t created.


#2

Thanks for bringing this to our attention, @azPHPguru. We’re looking into this now.


#3

Hey @azPHPguru,

Thank you for your question. In order for us to investigate further, I’d like to ask you for some additional information. Specifically,

  1. The entire request and response bodies (using twurl if applicable)
  2. The timestamp when these errors occurred

Thanks!


#4

Request 1:

2016-09-14 23:15:53 UTC POST https://ads-api.twitter.com/1/accounts/18ce5463v2o/product_feeds { "name":"REDACTED Feed 20160914", "url":"http:\/\/REDACTED.DOMAIN\/external\/product_feeds\/1807479521\/1807479521_twitter.tsv" }

Response 1:

{"errors":[{"code":"SERVICE_UNAVAILABLE","message":"Service unavailable due to request timeout; please try the request again later"}],"request":{"params":{}}}

Request 2:

2016-09-14 23:20:31 UTC POST https://ads-api.twitter.com/1/accounts/18ce5463v2o/product_feeds { "name":"REDACTED Feed 20160914", "url":"http:\/\/REDACTED.DOMAIN\/external\/product_feeds\/1807479521\/1807479521_twitter.tsv" }

Response 2:

{"errors":[{"code":"DUPLICATE_DETECTED","message":"A feed with the same url already exists"}],"request":{"params":{}}}

Hope it helps!