I’m experiencing the same critical issue with Google Calendar sync in SuiteCRM 8.8 on PHP 8.3, and I want to clarify that this is not related to scheduler misconfiguration — the scheduled sync is running perfectly every minute.
The core issue:
The OAuth access token is being refreshed successfully and appears to be saved using setPreference() and savePreferencesToDB(). But despite this, every subsequent run treats the token as expired, resulting in the same cycle:
- Scheduler runs and loads the access token from user preferences
isAccessTokenExpired()returnstrue- A new token is fetched and logged as successfully saved
- On the next run, it repeats — never reusing the token just saved
What I’ve discovered:
This isn’t just a logic bug — it appears to be tied to SuiteCRM’s session behavior, particularly in CLI (cron) context:
- Either the token isn’t actually saved to the DB despite the success log, or
- The session data (
$_SESSION[...]) used to track preference state is reset or not properly restored when cron runs again
So even though setPreference() sets the value and savePreferencesToDB() reports success, the system still loads an outdated or blank token on the next run. This suggests the refreshed token isn’t truly being persisted or is being lost between runs — possibly because SuiteCRM stores preferences in session and relies on session state even in CLI mode.
Why this matters:
This did not happen in SuiteCRM 8.3 under the same environment. It only started after upgrading to 8.8. So this looks like a regression, possibly due to session changes or stricter behavior introduced in 8.8 or triggered by PHP 8.3.
Suggestion:
The OAuth logic needs to force-load preferences from the database explicitly during cron execution and not rely on session state to persist values between runs.