Random 404 responses from airtable api

Thank you for your response Evan, I was a little disappointed in Bill’s response, so hopefully with your help we can get to the bottom of this!

Additional information:

1. There are other collaborators, but they are not changing the names of the tables. To be clear the error is always about the table being not found I’m looking for records (which are there) inside the table and it’s saying the table is not found.
2. I’ll look into the pattern idea, it’s difficult because the webhook runs very frequently and only 10% of the time (that’s a gut feeling) does it fail … more below.
3. It is getting close to Attachment space limits but it still has 6 GB. Are there other places I should look for limits to the base: https://www.dropbox.com/s/0l2w61cy1y8852v/Screenshot%202019-10-03%2011.07.10.png?dl=0 Like is there an API calls/requests limit?
4. I haven’t ever seen this error in postman. But I can try to trigger it.

I suspect it’s a frequency or a rate limit issue… meaning I’m making a ton of (possibly concurrent) calls to airtable via the API… this is why I would expect a different error code, something indicating rate limits exceeded etc. but getting a 404 table not found is VERY odd to me!

Here’s a brief log of the instances that ran via Zapier, those marked “scheduled” hit the 404 and are rescheduled to try again (this may sound ideal but it’s not, the 404 shouldn’t exist in the first place)

the above screenshot indicates that the pattern is not predictable imo

I’ve run this api call from postman 20-30 times just now and have not seen an error.

Developer on Airtable’s API team here.

For what it’s worth, we basically only return 404s in two cases:

1. the resource you’re fetching is missing. For example, if we can’t find the table, or the base, or the record, or whatever.
2. the URL you’re hitting is totally bogus. For example, a request to api.airtable.com/v0/garbage will return a 404.

It’s strange that you’re seeing this error intermittently, and nothing immediately comes to mind about why this would be failing. Any additional information you can provide is helpful. Things like:

1. are there any other collaborators who might be changing the name of the table and then changing it back? Probably not, based on what you described, but want to double-check.
2. does it happen on a pattern? For example, does it happen every 5 times, or every 10 minutes, or something like that?
3. is your base over any limits?
4. are you able to reproduce this by making similar requests yourself, perhaps using Postman or curl?

I’d love to get to the bottom of this, because it sounds spooky.

Does “whatever” include the possibility that his Zap is expecting a specific field and none exists in the GET response?

Paul,

If you read the error message from Zapier, they disclose a degree of ambiguity concerning 404’s. While the error message starts with a Table Missing indication, you must read further. Even they say that this is not a table missing error, but likely a field missing error.

From this, one might surmise that in 10 percent of the API calls, a field the Zap is expecting, is simply not in the API GET response.

Is that possible in your data?

Nope, not possible, since all the values for the GET are “hard coded” … meaning they are the same everytime this zap triggers and have no variables in them. I’m basically looking for a list of all records in a view… the zap is triggered on like a cron job, so there’s no “values” that change at this point in the zap, every 5 (ish) minutes the zap is triggered and the first thing it does is run this API call to query if any records are in this view. It handles empty resultset very well and there is no 404 because the table and view are found, it’s just an empty resultset.

Nope, not possible, since all the values for the GET are “hard coded” … meaning they are the same everytime this zap triggers and have no variables in them. I’m basically looking for a list of all records in a view… the zap is triggered on like a cron job, so there’s no “values” that change at this point in the zap, every 5 (ish) minutes the zap is triggered and the first thing it does is run this API call to query if any records are in this view. It handles empty resultset very well and there is no 404 because the table and view are found, it’s just an empty resultset.

How can that be in an API that does not return NULL or even EMPTY values?

Fair enough. I am no expert concerning Zapier and it’s great you are able to rule out Zapier as the possible cause. This leaves only Airtable as the source of the trouble.

I’m going to go way out on a limb here and predict that ultimately you will discover that a 10% failure rate involving your integration is attributed to a data condition that occurs only 1 in ten requests on average. I believe the answer is in your data (somewhere). If I’m wrong, I’ll buy you a nice turkey sandwich or a beer - your choice. :winking_face:

Edit #1: One recommendation - build the exact same GET request process using Google Apps Script and set it up for 5-minute intervals. Log all responses to a spreadsheet and then test to see what the failure rate is. At worst, you will have some good data for @EvanHahn to look at.

Edit #2: for the record…

But it also goes on to say that this is what [Zapier, possibly Airtable as well] reports “when a field value used in this step is missing”. Despite leading with “Table Not Found”, this is a typical ambiguity we often see in 404 errors. The true issue is likely related to the data and the expectations of Zapier, not a missing table. This leads me to one more question -

What if there is a result returned but it’s not a complete result - i.e., certain expected values are not present as JSON elements?

Fair enough. I am no expert concerning Zapier and it’s great you are able to rule out Zapier as the possible cause. This leaves only Airtable as the source of the trouble.

I’m going to go way out on a limb here and predict that ultimately you will discover that a 10% failure rate involving your integration is attributed to a data condition that occurs only 1 in ten requests on average. I believe the answer is in your data (somewhere). If I’m wrong, I’ll buy you a nice turkey sandwich or a beer - your choice. :winking_face:

Edit #1: One recommendation - build the exact same GET request process using Google Apps Script and set it up for 5-minute intervals. Log all responses to a spreadsheet and then test to see what the failure rate is. At worst, you will have some good data for @EvanHahn to look at.

Edit #2: for the record…

But it also goes on to say that this is what [Zapier, possibly Airtable as well] reports “when a field value used in this step is missing”. Despite leading with “Table Not Found”, this is a typical ambiguity we often see in 404 errors. The true issue is likely related to the data and the expectations of Zapier, not a missing table. This leads me to one more question -

What if there is a result returned but it’s not a complete result - i.e., certain expected values are not present as JSON elements?

I don’t understand what you are asking here?

Fair enough. I am no expert concerning Zapier and it’s great you are able to rule out Zapier as the possible cause. This leaves only Airtable as the source of the trouble.

I’m going to go way out on a limb here and predict that ultimately you will discover that a 10% failure rate involving your integration is attributed to a data condition that occurs only 1 in ten requests on average. I believe the answer is in your data (somewhere). If I’m wrong, I’ll buy you a nice turkey sandwich or a beer - your choice. :winking_face:

Edit #1: One recommendation - build the exact same GET request process using Google Apps Script and set it up for 5-minute intervals. Log all responses to a spreadsheet and then test to see what the failure rate is. At worst, you will have some good data for @EvanHahn to look at.

Edit #2: for the record…

But it also goes on to say that this is what [Zapier, possibly Airtable as well] reports “when a field value used in this step is missing”. Despite leading with “Table Not Found”, this is a typical ambiguity we often see in 404 errors. The true issue is likely related to the data and the expectations of Zapier, not a missing table. This leads me to one more question -

What if there is a result returned but it’s not a complete result - i.e., certain expected values are not present as JSON elements?

I’ll be waiting for the beer. :slightly_smiling_face:

As we know, an API request for a record that has 10 columns, five of which have data, will return that record without the empty fields represented in the result - i.e., . only five fields that actually have data.

Just a hunch - is it possible the Zap is accommodating two of three possible result occurrences and missing the third possibility where there is a result, but the payload is less than that needed for the Zap to process completely?

Bear in mind, the 404 you are getting from Zapier is an interpretation of the 404 Airtable may (or may not) be generating, right?

Again, I don’t know Zapier that well, but it is a middle-ware API service that must interpret and report errors from 1500 different APIs. How it handles each of them could be giving you inaccurate assessments of failure.

Nope, the text you’re reading is the “help text” from Zapier for API novices to say “hey, you might be getting an error from your API because one of the fields we sent to the API was empty” – it’s help text on any error with webhooks. In my case the values are all set and there’s no possibility for an “empty” value being sent to the API (all it is is GETing the records in a specific view)

Thank you for your response Evan, I was a little disappointed in Bill’s response, so hopefully with your help we can get to the bottom of this!

Additional information:

1. There are other collaborators, but they are not changing the names of the tables. To be clear the error is always about the table being not found I’m looking for records (which are there) inside the table and it’s saying the table is not found.
2. I’ll look into the pattern idea, it’s difficult because the webhook runs very frequently and only 10% of the time (that’s a gut feeling) does it fail … more below.
3. It is getting close to Attachment space limits but it still has 6 GB. Are there other places I should look for limits to the base: https://www.dropbox.com/s/0l2w61cy1y8852v/Screenshot%202019-10-03%2011.07.10.png?dl=0 Like is there an API calls/requests limit?
4. I haven’t ever seen this error in postman. But I can try to trigger it.

I suspect it’s a frequency or a rate limit issue… meaning I’m making a ton of (possibly concurrent) calls to airtable via the API… this is why I would expect a different error code, something indicating rate limits exceeded etc. but getting a 404 table not found is VERY odd to me!

Here’s a brief log of the instances that ran via Zapier, those marked “scheduled” hit the 404 and are rescheduled to try again (this may sound ideal but it’s not, the 404 shouldn’t exist in the first place)

the above screenshot indicates that the pattern is not predictable imo

I’ve run this api call from postman 20-30 times just now and have not seen an error.

Unlikely. It’s possible that we’re not returning a field for whatever reason, and then Zapier chokes on that (for some unexpected reason) and then, inexplicably, makes it look like we’re returning a 404. I think all of that is pretty unlikely, especially given the discussion above.

@Paul_Kortman Here’s a wild question: are all of these requests using the same User-Agent header? Are you able to see that in Zapier’s logs?

A less wild question: is there anything different between a successful request and an unsuccessful one, other than timestamps? Are the outgoing requests any different?

Another thought: could you set up a similar Zap pointing to a different base and see if the problem persists there? That could help us determine whether this is a broader issue.

We should be returning 429 status codes with a rate limited response (in other words, not a 404). It’s possible that we have a bug somewhere, but I’m pretty familiar with our rate limiting code and would be pretty surprised to see this.

Unlikely. It’s possible that we’re not returning a field for whatever reason, and then Zapier chokes on that (for some unexpected reason) and then, inexplicably, makes it look like we’re returning a 404. I think all of that is pretty unlikely, especially given the discussion above.

@Paul_Kortman Here’s a wild question: are all of these requests using the same User-Agent header? Are you able to see that in Zapier’s logs?

A less wild question: is there anything different between a successful request and an unsuccessful one, other than timestamps? Are the outgoing requests any different?

Another thought: could you set up a similar Zap pointing to a different base and see if the problem persists there? That could help us determine whether this is a broader issue.

Hi @Bill.French

Well, who gets a free beer? :grinning:

Kidding aside, I found this discussion quite interesting!

Mary K