Diagnose script interactions

[Richard_Foxwort]

I am trying to figure out an issue where attachments in my Airtable records are being deleted - allegedly by me according to the record history - when I am doing nothing of the sort.

I am using Integromat to create an Airtable record from incoming emails - the script includes populating an Attachments field in Airtable with certain email attachments.

I then have a native Airtable automation that classifies these incoming email message records based on their content and updates a Message_type field

That all works just fine, however in many, but strangely not all cases, the attachment then mysteriously gets deleted…

Here’s the record history pane from one of these records (I’ve obscured the data fields)

The Activity history shows the initial creation of the record via API, including an attachment, from Integromat, then the classification step using my Airtable script - in this case is a ‘no match’. All this script does is set a value in a ‘Message type’ field based on sting matching against content in the email body

But then the Activity history it shows the attachment is deleted - by me! But I did not delete it!

How can if work out what is actually driving this unwanted deletion of the attachment?

[M_k]

Hi @Justin_Barrett and @Richard_Foxworthy

You are right Justin, Google did an upgrade with GDrive and you now need the first two modules, in tandem, to work.

Hope this might help!

Mary K

[Richard_Foxwort]

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.

[Richard_Foxwort]

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.

[Bill_French]

Richard_Foxworthy:

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

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

[Martin_Kranz]

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

drive.google.com

Screen Recording 2020-12-10 at 13.19.15.mov (video)

Google Drive file.

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

[Martin_Kranz]

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

[Justin_Barrett]

@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).

[Bill_French]

Martin_Kranz:

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:

In my case, I was just working with individual files, so perhaps the issue only occurs with bigger batches.

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). :winking_face:

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?

[Martin_Kranz]

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

[Martin_Kranz]

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.

drive.google.com

Screen Recording 2020-12-10 at 13.58.15.mov (video)

Google Drive file.