Automations error (but not on Block): Response status was 302 'Moved Temporarily' but redirect mode was set to 'error'

[Mike_Mauer]

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.

[Jeremy_Oglesby]

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?

[Mike_Mauer]

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

[Jeremy_Oglesby]

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

[Bill_French]

Mike_Mauer:

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.

This is accurate; it’s always been this way (many years actually). But I wonder, would this header request addition help?

followRedirects: true

[Mike_Mauer]

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.

[Mike_Mauer]

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.

[Bill_French]

Mike_Mauer:

Functionally, this runs almost exactly the same way Airtable’s Automations would run, but it looks like Pipedream allows for redirects on GET requests.

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.

@Kasra?

[somehats]

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!

[Bill_French]

somehats:

we don’t currently support following redirects when using fetch in Automation scripts.

Hacky workaround -

• Make a POST, let it fail (because it probably succeeded).
• Let the called service backfill the Airtable table with a response/outcome.