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:

• PodioUnavailableError

• PodioError

• Internal server error

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:

• Flows that trigger on comments etc don’t run again because they’re missing some of their payload (like triggering comment).

• If Podio’s API is down for an extended period, this solution will make things worse because we’re hammering the API repeatedly.

• It is probably a good idea to use some kind of loop counter to ensure we don’t trigger the same flow on the same item over and over again (we can use set_var and get_var for this).

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