Pushing Podio
Search

GlobiFlow Error Recovery Musings

I love Podio, and GlobiFlow makes it even better. GlobiFlow automates the mundane, so you can concentrate on what’s important.

But every now and again, the Podio API hiccups and throws an error, stopping things in their tracks. I wish there were an auto-recovery process, but alas, there isn’t.

What I am about to propose is a musing, not a suggestion. Use the ideas to build on, but don’t just blindy implement this.

I’ve been playing around with ideas to re-fire hooks when flows fail due to specific Podio errors.

The errors that I’m most interest in are:

If you’ve never seen these in your GlobiFlow logs, just wait :-)

Step 1 - Capture Errors

The first thing I did was to create a new App in Podio to capture GF errors. The important part is that the app has a multi-line text field.

I then set up the email-to-app settings to ensure the email body is stored in the text field, and used the email-to-app address in GlobiFlow’s error log section:

So now, when an error happens in GF, and email is sent to Podio, and a new item is created in my new Errors App:

And the details are recorded from the email body:

Step 2 - Handle Errors

Now that we have the errors, we need to determine if we can do something, but before that, we need to parse out the details from the email.

I have a flow in the Errors app that triggers when an item is created there.

Sidebar - GF Sanity Checks

Before I continue, I just want to explain my flow structure a bit more. Flows can get very complex with multiple and nested sanity checks (if / end-if blocks).

To make things a little easier, I set a variable at the very beginning (in this flow called “run”).

Then in each subsequent sanity check, I only check the thing I’m interested in, as well as “run”, and if anything fails, set “run” to false.

This way the sanity checks stay a bit cleaner and have less nesting, etc.

Step 2 - Continued

OK, so first thing, I set “run” to “1”:

Next, get the flow ID from the email body:

We need to check to make sure the flow ID is usable:

Then get the item ID:

And make sure the item ID is valid:

Then we’ll extract the actual error message:

And make sure it’s an error we’re actually interested in:

Now, in order to use ProcFu to trigger this flow again, we need the app’s hook “c” and “p” values.

If you look at the hooks on any app that has GF flows, you’ll see them there:

For this particular app, c=1 and p=1267.

The c value is your GF customer ID. It will never change and is the same across all your apps, so you can use it directly.

The p value is GF’s internal ID for a given app in your account, so it will change from app to app.

For flexibility, I’m going to use ProcFu’s gf_get_p_value script to get the p value for the flow that just barfed:

Once again, it’s a good idea to make sure we have a usable p value:

And finally, if we’re still good to go, call ProcFu’s trigger_flow_on_item script to re-run the flow:

Considerations

As I mentioned in the beginning, this is a musing, and should be used as food-for-thought and not just blindly implemented.

Some issues I ran into:

All-in-all, I think this is the start of something that will be implemented in my setup shortly. I will however need to revise the flow to only run for specific high-importance flows when they error, and not just blanket-run for all errors.

Alternative Implementation

Another idea I’m working on is to just add a button in the errors app to re-process the flow. That might even be easier. It would require manual intervention, but removes the chance of infinite loops.

UPDATE: I have actually settled on the manual approach. You can read that post here: GlobiFlow Error Triage

(c) 2020 Globi Web Solutions | Join the Discussion in our Podio Workspace.