Diagnose script interactions

Thanks @Justin_Barrett and all, I will apply that second Gmail step which hopefully will work.

I’ve found a further variation on this that may be related - another of my file attachment scenarios also displayed this behaviour - guess I’m just lucky - but the Integromat scenario is different.

In this second case, I’m parsing a file download link from the email message body, then inserting the link into an Airtable Attachments field. This works often enough, but also fails regularly.

Airtable support had this to offer:

That activity in your revision history typically means Airtable was unable to process the attachment. So although it looks like it was uploaded and then deleted, it’s actually the case that we never had the full file. This could be due to the URL not being a publicly available URL (e.g., it requires a login to access), or the Integromat integration is sending URLs in a format we can’t parse.

Would you mind confirming that the URLs you’re sending are upload-able using the UI when you access the base itself? For example, if you click the “+” in an attachment field and select the the URL option below, does the file upload successfully that way?

And sure enough my example URL failed in the Airtable upload tool, even though it succeeds in my browser. I’ll re-engineer my Integromat flows to include an explicit save-file-to-GDrive step followed by the Get Share Link that @Justin_Barrett identified - -hopefully that will cure both my problems!

thanks again everyone for help on this.


Unfortunately this additional Gdrive step has proven not to solve my issue.

I’m now using an Integromat flow like this:

I have today found an example where the generated Gdrive Sharelink URL does work in the Airtable manual file upload tool, but it fails in the same way as before when the same URL is used from Integromat.

I’m using the ‘Web Content Link’ URL from the Integromat ‘get a share link’ module - this is a Gdrive URL with &export=download appended to the URL.

Which seems to suggest that this issue may actually be related.

following up on this @Justin_Barrett i am seeing the exact same thing here in spite of the sharing script.

this seems to work better in smaller batches than larger ones…

funnily, this happens JUST the same way with airtable’s own automations - once you pass this in bulk. I followed the approach here Native URL to Attachment which works, also with small arrays of attachments and does just fine in testing. But then, fails when triggered in large batches. @Justin_Barrett sorry for spamming but this is just data getting lost without as much as a confirmation

@Martin_Kranz I’m not sure how to address this. In my case, I was just working with individual files, so perhaps the issue only occurs with bigger batches. I suggest reaching out to Airtable support directly to make them aware of this and see if they can help. I’m just a fellow user, and at this point I’m out of ideas without delving deeper into further testing (which I’m afraid that I don’t have time to do at the moment).

I think we’re all chasing a ghost; an inherently unreliable and inconsistent upload feature that fails from time-to-time and sometimes involving many attachment attempts and sometimes for just a few attachment attempts.

It’s also likely there is at least one workaround and perhaps @Justin_Barrett has found one (or so he may think he has until he discovered he hasn’t). :wink:

23 days ago and 27 days ago I suggested this issue may be related to this well-documented collection of observations which are still being treated by Airtable as nothing more than typical user-related failures - i.e., pilot error. Responses like this from Airtable’s support group exhibit insensitivity to the deep details and tests the community has conducted across many similar threads.

From Airtable Support:
“So although it looks like it was uploaded and then deleted, it’s actually the case that we never had the full file. This could be due to the URL not being a publicly available URL (e.g., it requires a login to access), or the Integromat integration is sending URLs in a format we can’t parse.”

No person who has actually read all of the issues related to attachment uploads would respond in this fashion because nearly every thread includes validated tests where typical missteps have been accounted for and eliminated to demonstrate attachment failures.

This is like a RICO case; it must be prosecuted as a whole, not as individual support tickets.

Where is the product manager who can own this calamity and get it resolved?


I did actually read most of the documentation online - definitely public url, as the same url uploads just fine via the file upload in the UI, so this can’t be it, really. It’s definitely on the airtable side, as it happens the same way using their own automations.

I am also in touch with support about this, who respond the same way so it’s not looking like they have any knowledge to address this either. Their response sounds a LOT like what @Bill.French has pasted here.

PS apologies, i was under the impression you’re community moderator @Justin_Barrett

just for the record, i am attaching a screen recording of Justin’s scenario, mildly adapted to work with multiple upload urls per record they should be uploaded to, and how this fails to keep the files, even though in some cases names, mime type etc appear to be known to airtable to the extend of displaying this info in the ux.

I was referencing your own response from Airtable support which clearly indicates they have not studied the community’s conversations. No reasonable person could digest all that has been written about this topic and conclude that it is because we failed to provide publicly accessible URLs.

1 Like

No worries. I can see how the “Community Leader” label might create that impression, but it just means that a) I post a lot, and b) my ramblings tend to make sense more often than not. :wink: The only official mods are Airtable staff, who have the “Airtable” label by their names.

Just adding a little bit more info to this thread re an Airtable support recommendation that does not fix this issue.

Airtable support suggested modifying the GDrive link to remove &export=download from the end of the URL string - no idea why they’d suggest that since AFAIK this is the mechanism to tell GDrive we want a direct file download that skips the GDrive file viewer.

I tried it as follows:

Perhaps unsurprisingly, this does not solve the problem.

It’s actually a little more nuanced than this, and this article explains all of the different document access URL formats that Google supports. But setting this aside, you certainly need to provide Airtable with a publicly accessible URL that is not subject to an iFramed web viewer and I believe in all your tests this has been the case.

This is my point though - there’s a preponderance of data indicating a serious issue in the document attachment feature and it seems they just keep pushing the support narrative that we are not instrumenting the links properly or the links are not openly shared, or Google Drive must have been down. I think they need to appoint a special counsel on this one - someone who really owns the issue.

1 Like

Hi @Bill.French

I think they need to appoint a special counsel on this one - someone who really owns the issue.

I responded to Airtable support about how their suggested fix to remove &export=download from the URL does not work for me, and how this issue needs more serious attention, and got this rather encouraging reply:

Peter here, thanks so much for following back up about this. We have a few engineers on our team who are actually actively looking into this very issue, and I’d be happy to keep you updated about how their efforts progress. Hoping we can have this sorted out soon.

Let’s hope we see a fix sooner than later.

Good to hear.

I first reported this with 7 pages of documentation, repeatable tests, and some ideas exactly 360 days ago today. Support’s response was almost identical. I truly hope they mean it this time.

I have received the same message from the same Peter this week, also shared a example base with them so they could see it fail in real life. let’s hope they do something with it!

@Bill.French @Martin_Kranz here’s a little bit more from Airtable support:

Our engineering team has been taking a look into this issue, and are trying to get to the root of why these attachment uploads are failing (while it looks like the attachments are uploading and then getting deleted, the underlying behavior is just that the attachments are failing to upload. i.e. what you’re seeing is what normally happens when an attachment fails to upload).

Just to keep you on the same page – Airtable uses the service Filestack in processing attachments, and our working hypothesis is that Google Drive limits downloads from Filestack, which causes transient failures like those observed here.

The (relatively) good news is that when these files fail to upload, you should be able to simply retry uploading them at a later date. That said, we do not have very good signaling for attachment failures; the attachment value is just removed from the cell.

Also, to be up front, while our team is taking a look into this issue to fully understand it, it isn’t at this point clear when we might be able to have a full fix in place.

I’m not sure if they are suggesting there is a specific issue between Gdrive and Filestack - in which case swapping out Gdrive and replacing with Dropbox etc might help? And also, given that Airtable’s file upload is via Filestack, I guess this could mean that the problem is actually with Filestack rather than with Airtable per se?

Well, of course they do. All services have limits and likely watched very closely by Google. In fact, they probably have some quotas that are triggering when the Filestack system looks aggressive.

There have been tests that show this issue occurs with other services as well, but they may be blocking Filestack too. Besides, ruling out Google Drive is not an option; there are 100 million businesses using it.

There is some validity to this idea, however, immediate retries almost always fail; I’ve tested up to ten retries without success. And to be clear - AIRTABLE should implement this at the service instead of asking thousands of users to create a patchwork of crap to overcome this issue. We didnd’t pick Filestack, after all, eh?

Perhaps, but ultimately, the issue is with Airtable because we have no standing with Filestack.

1 Like

And here is another bit of info from Airtable support responding to a question if this issue is GDrive specific:

That’s correct – our understanding is that this issue is GDrive specific, so we wouldn’t necessarily expect this issue to occur in Dropbox (or another similar service). Please do let us know whether you have success with a different service (and sorry for not having thought to propose that kind of solution sooner).

Completely agree with you @Bill.French that buck must stop with Airtable, even if it’s specifically a Filestack <–> GDrive issue, but I intend try using a different cloud file system for now, and see it it alleviates the issue for me.

I thought I was crazy until I discovered this thread. Has anyone heard any update from Airtable?