- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 21, 2020 03:04 PM
Has anyone else experienced this?
I have a JSON object I am trying to fetch from Google Scripts Web App. It works great in the Block Script editor, but when I try to use the same code in the Automation block I receive this error:
TypeError: Response status was 302 ‘Moved Temporarily’ but redirect mode was set to ‘error’
This error is referring to the Google Script URL.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 21, 2020 03:21 PM
Yes! I am getting that same error just in the last 3 days, and only when it is run as an automation.
You can see below that it worked fine for several days, then 3 days in a row it failed, with the message you described (except mine says it was “permanently” moved):
In my case, the API I was using did change their URL scheme. But I adjusted my script to match their new URL scheme after that very first failure. I verified that it worked. Next day, it failed to fetch from the updated URL with the same error. Today, it seems to have corrected itself :man_shrugging: . Who knows?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 21, 2020 03:29 PM
Thank you and super interesting! Hope it corrects itself.
It looks like Google Scripts Webapps don’t actually expose the final URL for security reasons, so what’s served up as their endpoint is actually just a redirect.
For some reason, Airtable Scripting Blocks can follow that redirect correctly, but automations can’t.
To illustrate – the expected value returned is “128” here.
SCRIPTING BLOCK
AUTOMATION TOOL
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 21, 2020 03:41 PM
Ya – clearly it’s got something to do with the fact that scripts in the scripting block (or being tested in the automations interface) are running locally in your browser engine, whereas automations are running on a cloud server (probably AWS).
@Kasra, @Stephen_Suen, @Billy_Littlefield, @Zach_Felsenstein, @Jason – heads up
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 21, 2020 05:34 PM
This is accurate; it’s always been this way (many years actually). But I wonder, would this header request addition help?
followRedirects: true
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 21, 2020 06:59 PM
Thanks! I’m unfamiliar with the followRedirects parameter but I gave it a shot in the header and it didn’t work. I also tried the “redirect: follow” parameter and received this error:
That does appear to confirm the issue. Wonder if there are any workarounds.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 21, 2020 09:00 PM
Update: I was able to write a workaround using Pipedream.
Workflow was Airtable view trigger > node.js script that fetches the Google Script JSON object > Airtable Patch to update cells
Functionally, this runs almost exactly the same way Airtable’s Automations would run, but it looks like Pipedream allows for redirects on GET requests.
If there’s interest I’m happy to share the workflow.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 22, 2020 08:25 AM
This seems to be an accurate assessment of the issue.
I think the right approach (when attempting to create a seamless integration between Action Scripts and Google Apps Script) is to make requests using the redirects : "follow"
option in Fetch().
let postOptions = {
method: "post",
headers: {
'Accept' : 'application/json'
},
redirect : "follow",
body: JSON.stringify(payload)
}
When doing so, the error message is far more revealing: :slightly_smiling_face: Airtable simply doesn’t support the ability to follow API platforms that require response redirects. I also see no workaround for harvesting the response.header.location
to perform the correct [redirected] request.
I believe Airtable needs to remedy this and soon because it makes it entirely impossible to integrate Google Apps Script, Google Cloud Platform, and many other systems that use this technique for stringent security measures.
My workaround (for now) is a Firebase or Google Cloud function as the proxy much the way @Mike_Mauer has done with PipeDrive.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 24, 2020 06:49 AM
To confirm, as @Bill.French says, we don’t currently support following redirects when using fetch in Automation scripts. The differences from fetch in the browser section of the automation scripts API docs has some more details of this and other limitations of fetch
in automations at the moment.
We can’t share a timeline for when redirects might be supported, but thanks so much for the feedback - it’s super helpful for us prioritizing work on this sort of thing in the future. Let us know if you come across any other use-cases where you need redirects in automation scripts!
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 10, 2021 01:10 PM
Hacky workaround -
- Make a POST, let it fail (because it probably succeeded).
- Let the called service backfill the Airtable table with a response/outcome.