fix: register all cron jobs in twenty-app-dev image - #20167
Conversation
The dev image previously passed `--dev-mode` to `cron:register:all`, which skipped calendar, messaging, and workflow sync cron jobs. This caused periodic sync to silently stop after the initial import for community members running the dev image as their actual instance. The cron jobs gracefully no-op when no connected accounts exist, so there is no downside to registering them all. Removing `--dev-mode` entirely since it was only used by the dev image. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![cubic-dev-ai[bot]](https://avatars.github.com/in/1082092?s=60&v=4){kind=small}
📊 API Changes ReportGraphQL Schema ChangesGraphQL Schema Changes[error] Error: Unable to read JSON file: /home/runner/work/twenty/twenty/main-schema-introspection.json: Not valid JSON content GraphQL Metadata Schema ChangesGraphQL Metadata Schema Changes[error] Error: Unable to read JSON file: /home/runner/work/twenty/twenty/main-metadata-schema-introspection.json: Not valid JSON content REST API Analysis ErrorError OutputREST Metadata API Analysis ErrorError Output |
## Summary The dev seeder creates `ConnectedAccount` records with fake OAuth tokens (`'exampleRefreshToken'` / `'exampleAccessToken'`) and points `MessageChannel` / `CalendarChannel` records at them with `isSyncEnabled: true`. When the sync cron jobs run in the demo workspace, they: 1. Pick up these seeded channels (filter is `isSyncEnabled: true` + pending sync stage) 2. Try to refresh the fake OAuth tokens 3. Mark the channels as `FAILED_INSUFFICIENT_PERMISSIONS` 4. Surface a "Sync lost with mailbox X — please reconnect" banner in the UI This banner appears every time the demo workspace is loaded, even though nothing is actually broken. ## Fix Set `isSyncEnabled: false` on all 12 seeded channels (6 message, 6 calendar). This is the canonical "don't sync this channel" mechanism — the same state a real user lands in when they toggle sync off in account settings. ## Why this approach - **ConnectedAccount records stay**: the demo workspace still shows Tim, Jony, Phil, Jane as having connected their email/calendar — realistic - **Pre-seeded messages and calendar events stay visible**: those don't depend on `isSyncEnabled` - **Crons no longer pick them up**: they filter on `isSyncEnabled: true`, so `false` short-circuits the entire sync attempt — no failure, no banner - **Semantically correct**: the seeded accounts have fake tokens that were never going to sync successfully; `isSyncEnabled: true` was effectively a lie - **No production code touched**: no `isDemo` flags, no magic-string detection, no workspace-ID filters in the cron path ## Alternatives considered and rejected - **Add an `isDemo` flag**: schema change, leaks demo knowledge into production tables - **Skip channels with fake tokens (`example*` pattern)**: hacky magic-string detection in the auth refresh path - **Filter demo workspace IDs in the cron**: production paths shouldn't reference demo IDs - **Don't activate demo workspaces**: breaks the demo workspace UX entirely ## Test plan - [ ] Reset the database and reseed (`npx nx database:reset twenty-server`) - [ ] Load the demo workspace — confirm no "Sync lost with mailbox" banner appears - [ ] Confirm seeded connected accounts still show in Settings → Accounts - [ ] Confirm pre-seeded messages and calendar events still appear in the UI - [ ] Confirm a real connected account (added via OAuth) still syncs normally — its channel will have `isSyncEnabled: true` and the cron will pick it up ## Related Companion to #20167, which removes the `--dev-mode` cron filter that was masking this banner issue in the dev image. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2 participants
Summary
The
twenty-app-devDocker image previously passed--dev-modetocron:register:all, which skipped all calendar, messaging, and workflow sync cron jobs (only 4 generic crons were registered). This caused periodic sync to silently stop after the initial import for community members using the dev image as their actual instance.What changed
--dev-modeflag frompackages/twenty-docker/twenty-app-dev/rootfs/etc/s6-overlay/scripts/register-crons.shso the dev image registers all cron jobs (matching production behavior)--dev-modeoption,DEV_MODE_COMMANDSset, and conditional filtering logic fromcron-register-all.command.tsWhy this is safe
Context
Surfaced by a community member who reported that calendar sync cron jobs never appeared in the queue after restarting the dev image, and only the initial import worked.
--dev-modewas added in #19138 as an optimization for development but it doesn't match how the dev image is actually used by community members deploying Twenty.Test plan
twenty-app-devimage🤖 Generated with Claude Code