Notification when Fetch stops

TomBoston

Fetch randomly stopped for us today. Reauthenticating with OAuth2 resolved.

I’m looking for a way to be notified when fetch stops on its own.
I’ve created a script that sends mail based on this query:

SELECT if(((last_activity - NOW()) * -1) > 300, 'yes', 'no') as fetch_test FROM osticket.ost_email_account WHERE id =3;

This works when fetch is disabled intentionally and I await a moment when it stops working (same as it did today) to see if the script also works then.

Another field in that same table, called “updated,” logs the same timestamp as “last_activity.”
Does anyone have other ideas on how to send notification if fetch is either off or just randomly not working?

KevinTheJedi

TomBoston

You can look at that as well as the last_error and last_error_msg columns. If fetching has fatal issues they will be logged there.

Also, you should upgrade osTicket and your OAuth2 plugin to the latest to avoid the token expiration issue. Tokens Expiring and not being refreshed was an issue back in the day but ever since v1.17.2 (I believe) and the new builds of the plugins at that time we addressed the issue.

Cheers.

TomBoston

Thanks for the reply!
There's no entry in either "last_error" or "last_error_msg."
I am wondering if that has any meaning in my case.
Would the token expiration issue generate entries there?

KevinTheJedi

TomBoston

Yes, it would. Unless you’ve already got a new token and next auth was successful then they both get cleared.

Cheers.

TomBoston

Thanks!

I’ve updated the script so it now also searches for entries in the "last_error" field.

The first check (the one that checks last_activity) runs every three minutes, and for what this is worth, sometimes it alerts once, right around the hour, but then the alert stops and fetch is working normally. This could be caused by something specific in my environment, possibly at the OS or database level. Not sure. Just passing this along for what it's worth.

KevinTheJedi

TomBoston

What is the Redirect URI you have in the plugin instance config? Basically, is it reachable from the server itself via CLI? When it auto-renews it will use PHP-CLI which calls directly from the server instead of your browser. So if the URI is unreachable at the server level then that will be an issue.

We haven’t had any reports of non-renewing tokens since v1.17.2/3 and the latest build of the OAuth2 plugin at that time. The initial issue was the plugin wasn’t updating the Access Token AND Refresh Token only the Access Token. So after the Refresh Token expired (around 30 days) it would fail to renew and cause such issues.

However if yours is failing every hour or couple of days then something else seems to be at play.

Cheers.

TomBoston

Just a final thought on this.
From what I can tell from my homespun alerts, they seem to indicate the fetch is not running during a tiny window just before each hour. In other words, the fetch is not failing (there's no error message), it's just not running. So, maybe something during that very short window is preventing the fetch from starting up.
It's not hindering us at all.
Thanks for all the help!

KevinTheJedi

TomBoston

What does your cron job look like? It’s possible this is not configured as expected which is causing the non-fetch.

Cheers.

TomBoston

So the issue was in the syntax of my query. I revised it by putting both time values in seconds before making the calculation.

Our fetch runs every minute, so if “last_activity” is older than 120 seconds, I receive an email message.

SELECT if(TIME_TO_SEC(NOW()) - TIME_TO_SEC(last_activity) > 120, 'yes', 'no') as fetch_last_activity FROM osticket.ost_email_account WHERE id =3;

Thanks again!