What happens
When actual-ai is left running as a persistent container (internal cron via CLASSIFICATION_SCHEDULE_CRON), the daily bank sync quietly stops bringing in new transactions once the process has been alive for a long stretch. There is no crash and no error: RestartCount stays at 0 and every run still logs Bank accounts synced normally, yet nothing new is imported even though the server has newer transactions waiting.
This is a different failure mode from the existing crash-on-failed-sync reports. Nothing throws here; the process simply goes quiet.
How I noticed
- The container had been up for a long time, no restarts, clean logs.
- The daily run kept reporting the same total transaction count, day after day.
- Triggering a manual Sync from the Actual web UI pulled the missing transactions in right away, so the data was reachable the entire time.
- A single restart of the actual-ai container fixed it instantly. On boot, the fresh process reported a large batch of
messages from server that the long-lived process had never received, and the totals jumped to include the missing days.
Why I think it happens
classify() already re-runs initializeApi() / shutdownApi() on every cycle, so per-run setup is being done correctly. The telling detail is that the restart recovered everything using the same on-disk dataDir (a plain restart does not clear it), which means the persisted data was fine. What was stale was the in-memory state inside @actual-app/api, whose init() / shutdown() are module-level singletons. Reused across many cycles inside one long-lived process, that state appears to drift until incremental sync returns 0 messages indefinitely. Only a fresh process clears it.
Possible directions
- Document that the persistent / internal-cron mode can drift over time, and recommend the run-once-and-exit style (
classifyOnStartup with no cron, plus an external scheduler) for long-term reliability.
- Or, in cron mode, run each scheduled tick in a fresh child process so every run gets clean
@actual-app/api state while the container stays up.
Environment
actual-ai 2.4.0 - SimpleFIN bank sync - Docker Compose - FEATURES includes classifyOnStartup and syncAccountsBeforeClassify
What happens
When actual-ai is left running as a persistent container (internal cron via
CLASSIFICATION_SCHEDULE_CRON), the daily bank sync quietly stops bringing in new transactions once the process has been alive for a long stretch. There is no crash and no error:RestartCountstays at 0 and every run still logsBank accounts syncednormally, yet nothing new is imported even though the server has newer transactions waiting.This is a different failure mode from the existing crash-on-failed-sync reports. Nothing throws here; the process simply goes quiet.
How I noticed
messages from serverthat the long-lived process had never received, and the totals jumped to include the missing days.Why I think it happens
classify()already re-runsinitializeApi()/shutdownApi()on every cycle, so per-run setup is being done correctly. The telling detail is that the restart recovered everything using the same on-disk dataDir (a plain restart does not clear it), which means the persisted data was fine. What was stale was the in-memory state inside@actual-app/api, whoseinit()/shutdown()are module-level singletons. Reused across many cycles inside one long-lived process, that state appears to drift until incremental sync returns 0 messages indefinitely. Only a fresh process clears it.Possible directions
classifyOnStartupwith no cron, plus an external scheduler) for long-term reliability.@actual-app/apistate while the container stays up.Environment
actual-ai 2.4.0 - SimpleFIN bank sync - Docker Compose -
FEATURESincludesclassifyOnStartupandsyncAccountsBeforeClassify