feat(local): run calendar_service in the local stack as the calendar owner - #6755
Conversation
…owner Add calendar_service to the local stack on port 8088 and make it the local owner of calendar. It joins the service inventory as a Local-only service (its backfill SQS workers spawn unconditionally, so running it under run_dev would race the deployed calendar-service for its backfill queue), which gives it a generated /calendar Caddy route and includes its binary in the local runtime image. LocalStack provisions its backfill queue, and an in-network OVERRIDE_CALENDAR_SERVICE_URL lets service-to-service callers (the agent calendar tools) reach it by container alias. The email service's calendar sync is disabled locally (a per-service compose override) so only one service syncs the shared MacroDB; with sync off it also stops mounting its /calendar mutation routes. The web client's calendar-service host is flipped to calendar_service (localhost:8088/calendar directly, the proxy's /calendar route otherwise).
|
Understand this PR’s impact Explore downstream dependencies and potential security impact with Blast Radius. Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: macro-inc/macro/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: macro-inc/macro/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (8)
Included review availability: Your plan provides up to 8 included reviews per hour; 1 remains after this review. 📝 SummarySummary by CodeRabbit
WalkthroughThe local stack now uses a dedicated Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to No actionable merge-blocking risk remains; the new calendar service preserves the intended access controls. 🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit bc2e689. Configure here.
The calendar sync scheduler and outbox drain run in the pubsub_workers binary (email_service::calendar_outbox::run), not the email HTTP service, so the CALENDAR_SYNC_ENABLED=false override has to be on email_pubsub_workers as well — otherwise that worker keeps syncing calendar and double-writes the shared local MacroDB alongside calendar_service.
1 participant
Runs
calendar_servicein the local stack on port 8088 and makes it the local owner of calendar, mirroring where dev/prod are heading.calendar_servicewas already built and deployed dormant; locally it was absent, and the web app reached calendar throughemail_service. This wires it into the stack the same way its siblings are and hands calendar over to it.What changed
xtask_local): acalendar_serviceentry (composecalendar_service, bin/packagecalendar_service, host port 8088, proxy prefix/calendar). The generated Caddyfile now fans/calendartocalendar_service:8080, and its binary joins the local runtime image. NewPort::Calendar = 8088, appended so per-instance port offsets stay stable.docker/docker-compose.yml): acalendar_serviceservice (8088→8080,calendar-servicenetwork alias,/healthcheck) and a per-serviceCALENDAR_SYNC_ENABLED=falseoverride onemail_service.calendar-serviceadded tolocalStackDeployServiceNames(its binary definition already existed).xtask_local):OVERRIDE_CALENDAR_SERVICE_URL=http://calendar-service:8080so in-network callers (the agent calendar tools) reach it by container alias instead of the host-port default.CALENDAR_SYNC_ENABLED=trueis already set globally, socalendar_serviceinherits it.calendar-service-backfill-queueis provisioned in LocalStack and bound through the queue's own override var in URL form, so the always-on backfill workers dial a full queue URL rather than a bare name.servers.ts): thecalendar-servicehost flips from the email-service stopgap tocalendar_service—http://localhost:8088/calendardirect,${proxyOrigin}/calendarthrough the single-origin proxy.The local-cutover decision
Both
calendar_serviceandemail_serviceread oneCALENDAR_SYNC_ENABLEDflag that gates both their calendar sync workers and their/calendarmutation routes. Two services syncing the one shared local MacroDB would double-write, so exactly one may own it. This turnscalendar_serviceon andemail_serviceoff, so local reflects the post-cutover world:calendar_serviceruns the sync scheduler + backfill and serves the mutation routes,email_serviceserves neither.calendar_serviceruns local-only (not underrun_dev): its backfill SQS workers spawn unconditionally, so a local instance pointed at shared-dev resources would race the deployedcalendar-servicefor its backfill queue — the same reasonscheduled_actionis local-only.Relationship to #6752
Builds directly on #6752 (which moved the web calendar client onto a
calendar-servicehost and, as a stopgap, pointed it back atemail_service's/calendarroutes). This flips those stopgap values to their final targets now that the service is in the stack. It has to merge after #6752: thefrontend_wires_every_inventory_prefixdrift test requires the/calendarinventory prefix to have a matching${proxyOrigin}/calendarentry inproxyServers(), which #6752 introduces.Config
No Doppler changes. Everything
calendar_servicerequires (MACRO_DB_URL,REDIS_URI,KAFKA_BROKERS,AUTHENTICATION_SERVICE_SECRET_KEY,INTERNAL_API_KEY, and themacro_authJWT vars) already comes from the code-owned local env and boot stubs, which apply in both Doppler and--no-dopplermodes. The email flag is a repo-side compose override, so nolclvalue matters.Left out
The dev/prod cutover (flipping the deployed flags and eventually retiring
email_service's calendar routes) is separate infra/Doppler work and is not part of this local-stack change.Note
Medium Risk
Changes which service owns calendar sync and API routes locally; misconfiguration could break local calendar or double-write MacroDB, but scope is dev/docker/xtask only—not deployed prod cutover.
Overview
Adds
calendar_serviceto the local stack as the sole owner of calendar: compose on 8088, xtask inventory/Caddy/calendarrouting, Nix binary packaging, LocalStack backfill queue binding, andOVERRIDE_CALENDAR_SERVICE_URLfor in-container callers.Local cutover: sets
CALENDAR_SYNC_ENABLED=falseonemail_serviceandemail_pubsub_workersso onlycalendar_servicesyncs the shared MacroDB (email stops serving/calendarmutations locally).calendar_serviceis registered as local-only in inventory (same pattern asscheduled_action) to avoid backfill queue races against shared-dev.Web:
servers.tsstops routing calendar through email (8087//email/calendar) and pointscalendar-serviceat8088/calendarand${proxyOrigin}/calendar.Reviewed by Cursor Bugbot for commit 481ac2b. Bugbot is set up for automated code reviews on this repo. Configure here.