Hi all,
I have an automation that uses the suggested code from @Tim in here (super useful thanks by the way):
So when a webhook comes in I extract the url and then save the image in a field as explained there.
For some reason this was working until last Saturday (April 5th) (this is the latest I can traceback a working example). Now I get a broken image placeholder every time. I just realized this now but while investigating this I also realized that yesterday this wasn’t working already. So without really “touching” or doing anything to the workflow or code this stopped working. I already verified that the urls are still correct and offering a valid image that can be downloaded.
It may have to do with something that fundamentally impacted this:
// download your image via the external URL
const url = image_field_via_url_field_url_value;
const { data: file_content } = await http.get(url, {responseEncoding: 'binary'});
// upload the downloaded image to Tape
const encoded_file_content = Buffer.from(file_content, 'binary');
const { data: uploaded_file } = await tape.File.upload({filename: 'image.png', source: encoded_file_content});
// update current record using the uploaded file reference
const uploaded_image_file_id = uploaded_file.file_id;
await tape.Record.update(current_record_id, {fields: {image:uploaded_image_file_id }})
I use this code with the silent flag on it as well.
Could you please check if there was any change that may have led to this? Or if there is any problem regarding this?
This is quite a critical automation in this case so I would greatly appreciate your checks here.
Finally this was a url redirection problem. The url provider changed it in a way that is now redirecting to another url. The thing is this http.get is not handling redirects by default.
Thank you very much @Jason for your help! Jason helped a lot, especially in the final solution implementation to handle this properly.
I thought it might be worth posting the workaround here in case others run into the same issue – which you will if you’re using Tally forms to send file uploads into Tape (@tomaz).
As R.J. discovered, Tape doesn’t automatically follow 302 redirects. That means the original code being used fails when trying to retrieve attachments from Tally. However, a 302 redirect should always include the new URL in the location header. So we can simply grab that URL from the first response and make a second GET request to fetch the file.
Here’s how we updated the code (this is taken from one of my automations that was also using Tally):
const imageUrl = jsonata(`*.fields[key="question_XrL9oV"].value.url`).evaluate(webhook_payload_parsed);
const rid = jsonata('record_id').evaluate(record_collection_demo_2413007___orders);
console.info(`Record ID: ${rid}`);
// download your image via the external URL
const response = await http.get(imageUrl, {responseEncoding: 'binary'});
const statusCode = response.statusCode;
let file_content;
if (statusCode === 302) {
const newURL = jsonata('headers.location').evaluate(response);
console.info(newURL);
const { data } = await http.get(newURL, {responseEncoding: 'binary'});
file_content = data
} else {
file_content = response.data
}
// upload the downloaded image to Tape
const encoded_file_content = Buffer.from(file_content, 'binary');
const { data: uploaded_file } = await tape.File.upload({filename: 'sig.png', source: encoded_file_content});
// update current record using the uploaded file reference
const uploaded_image_file_id = uploaded_file.file_id;
await tape.Record.update(rid, {fields: {signature:uploaded_image_file_id }})
So essentially, we try to download the image from the initial URL, and if the response is a 302, we follow the location header to the new URL and download the file from there. If it’s not a 302, we assume we got the file on the first try.
I threw this fix together fairly quickly, so there’s definitely room to make it more robust. But for a quick workaround to the Tally forms issue – and hopefully something that’ll still work if/when they stop using redirects – I think it does the trick.
(I’m not 100% sure, but I vaguely remember @dirk_s also running into issues with redirects a while back.)