Conversation
laprasoc
force-pushed
the
codex/macos-support
branch
from
899a7d0 to
9513ea6
Compare
|
|
||
| installHourlyGitSyncScript({ fs, openclawDir: OPENCLAW_DIR }); | ||
| await installHourlyGitSyncCron({ fs, openclawDir: OPENCLAW_DIR }); | ||
| await installHourlyGitSyncCron({ |
There was a problem hiding this comment.
On macOS, the managed scheduler only starts during process startup in bin/alphaclaw.js when the sync script already exists. In a fresh onboarding flow, we create the script/config here, but never start the scheduler in-process afterward, so hourly sync will not run until the service restarts. Can we start the managed scheduler after successful cron config install on darwin (or have installHourlyGitSyncCron do that) so onboarding is immediately effective?
| const normalizeCronPlatform = (platform = os.platform()) => | ||
| platform === "darwin" ? "darwin" : "linux"; | ||
|
|
||
| const isValidCronSchedule = (value) => |
There was a problem hiding this comment.
isValidCronSchedule currently accepts any 5-token expression, but the managed scheduler matcher below only supports numeric tokens (*, ranges, steps, comma lists). Schedules like 0 9 * * MON will be accepted/saved but can never match on macOS, so sync silently never runs. Can we either tighten validation to supported syntax or add parser support for named day/month tokens?
chrysb
left a comment
chrysb
left a comment
There was a problem hiding this comment.
Great direction overall on macOS support and shared cron plumbing. I'm requesting changes for two blockers:
- On fresh macOS onboarding, the managed scheduler is not started after cron/script install, so hourly sync does not run until a restart.
- Cron validation accepts schedules the managed parser cannot execute (e.g. named weekdays), which can silently disable sync on macOS.
I left inline comments on both code paths with suggested fixes.
2 participants
Summary
/etc/cron.dwhile macOS runs the saved five-field cron schedule from AlphaClaw's managed in-process schedulergogand shim binaries into AlphaClaw's managed internal bin on macOS instead of assuming/usr/local/binALPHACLAW_ROOT_DIRandPORTare resolved before server constants are imported, which makes local macOS roots and ports behave correctlyTesting
npm test -- tests/server/routes-system.test.js tests/server/routes-onboarding.test.jsnode bin/alphaclaw.js --root-dir /tmp/alphaclaw-live-test startagainst an existing local.openclawon macOS