calendar sync: nightly sync forces updates and skips the per-user lock

Open Beginner friendly
#678 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rails, ruby
Domain
api, backend

Research direction

Start with app/jobs/nightly_calendar_sync_job.rb and config/recurring.yml, then read app/jobs/google_calendar_sync_job.rb and its specs. Check how the nightly job selects users and how the sync job accepts force; add a spec asserting one sync job is enqueued per user. Done when the nightly job delegates each user sync without forcing unchanged events.

Written by the indexing model from the issue text.

Description

performance v/6

Found in the #654 audit.

Problem

app/jobs/nightly_calendar_sync_job.rb runs every 6 hours (config/recurring.yml).

  • Users with calendar_needs_sync = true sync with force: true (line 22). In GoogleCalendarService (if force || existing_event.data_changed?, about line 115), force sends an update_event call for every event, also for events that did not change. One course title change during registration can send 20 to 50 Google API calls for each enrolled user.
  • The job syncs all users inline, one after the other, in one worker thread. It does not use GoogleCalendarSyncJob, so it does not use limits_concurrency (google_calendar_sync_job.rb:6). A nightly sync and a user sync for the same user can run at the same time and make duplicate events.

Fix

  1. Enqueue GoogleCalendarSyncJob.perform_later(user, force: false) for each user. data_changed? already skips events that did not change.
  2. If force is necessary for a case, write down which case and keep it for that case only.
  3. Add a spec that the job enqueues one sync job for each user.

Effort: small to medium.

Dominant language
Ruby
Stars
4
Forks
0
Avg merge
6h 36m
Merged PRs (30d)
181

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WITCodingClub/calendar-backend

All issues in WITCodingClub/calendar-backend

Similar issues

More Ruby issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.