Academy / Week 3 / SyncApp Code Flow & Creating a New Integration / Code Flow Part 2 — RunSyncFunctions & Batch Syncer Lock

Code Flow Part 2 — RunSyncFunctions & Batch Syncer Lock

Lesson 13.2⏱ ~8 minWeek 3

💡 Why This Matters

RunSyncFunctions is the heart of SyncApp — it's the loop that executes every registered sync function on every cycle. Understanding how it uses the singular instance check and locks the batch syncer explains why concurrent syncs don't corrupt data.

🎯 What You'll Learn

  • How RunSyncFunctions creates a singular instance and retrieves the list of registered sync functions
  • Why the batch syncer is locked before sync functions run — it's a critical shared resource
  • How the loop iterates over sync functions, checks the function name, and evaluates eligibility
  • What the singular instance returns (yes/no): whether a function is eligible to run right now
  • Why this design prevents two instances of the same sync function from running simultaneously

Watch Video

Open in Google Drive 💡 Open in Drive for AI-powered transcript search

📋 Lesson Summary

RunSyncFunctions is called on every SyncApp cycle. It first creates a singular instance — a per-function lock tracker. Then it locks the batch syncer (a critical shared resource — nothing else should write to it while syncing). It then loops over all registered sync functions, checks each function's name, and asks the singular instance: 'is this function eligible to run?' The singular instance says yes if no other instance of that function is currently running. This prevents a slow patient sync from being re-triggered before it completes, which would cause data corruption.

🏷 Key Concepts

RunSyncFunctionsSingular InstanceBatch Syncer LockSync Function LoopEligibility CheckConcurrent Execution PreventionCritical ResourceFunction Name Check

Key Takeaways

01RunSyncFunctions is the central loop — everything in SyncApp flows through here
02The batch syncer lock means only one sync operation runs at a time — this is intentional for data integrity
03The singular instance check is per function — patient sync and appointment sync can't both run simultaneously if they share resources
04If a sync function is running slowly, subsequent scheduled runs are skipped (not queued) until it completes
05Understanding this loop is essential for debugging 'sync stuck' or 'sync not running' issues