511d11ce72
The backup automation was scheduled with `npx runfusion.ai backup --create`, which spawns whatever fusion binary is on PATH. On developer machines that's usually an older globally-installed runfusion.ai (v0.13.0 at time of writing) which still carries the pluginStore-rootDir bug — every backup tick recreated `<project>/.fusion/.fusion/` with a fresh empty TaskStore. Cron-runner and routine-runner now intercept any command matching `fn backup`, `fusion backup`, or `npx runfusion.ai backup` and call `runBackupCommand` directly via the engine's open TaskStore. The interception also handles existing schedules persisted with the old npx command, so users do not need to manually update their automation rows. The default command for newly created backup schedules is also simplified to `fn backup --create` — both forms route through the same in-process executor. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
834 B
@runfusion/fusion
| @runfusion/fusion |
|---|
| patch |
Run the auto-backup automation in-process instead of shelling out to whatever fusion binary happens to be on PATH. The cron and routine runners now intercept commands matching fn backup, fusion backup, or npx runfusion.ai backup and call runBackupCommand directly through the engine's already-open TaskStore. This stops the auto-backup from launching an outdated globally-installed fusion binary that could re-introduce already-fixed bugs (most recently the pluginStore rootDir mistake that created a stray .fusion/.fusion/ directory each time the schedule fired). New backup automations are also written with the simpler fn backup --create command — existing schedules using the old npx runfusion.ai form keep working because both forms hit the same in-process interception.