Upper bound (10 minutes) on how long a single app-driven ("automatic") Send/Receive is allowed to
run — one the app starts itself rather than the user driving it from the Send/Receive dialog
(which has its own progress and Cancel). A sync of a large repo can run for minutes, so this is
deliberately long.
Consumed by the main process (shutdown-tasks.ts), which uses it to bound how long app shutdown
waits on its final sync. It also conceptually matches the C# write gate's stall watchdog, which
bounds the same "one automatic Send/Receive" window. The renderer does not time blocking locally
— it reads the backend write gate's snapshot (auto-sync-blocking-store.ts), so blocking clears
when the backend says so rather than on a renderer-side timer.
Upper bound (10 minutes) on how long a single app-driven ("automatic") Send/Receive is allowed to run — one the app starts itself rather than the user driving it from the Send/Receive dialog (which has its own progress and Cancel). A sync of a large repo can run for minutes, so this is deliberately long.
Consumed by the main process (
shutdown-tasks.ts), which uses it to bound how long app shutdown waits on its final sync. It also conceptually matches the C# write gate's stall watchdog, which bounds the same "one automatic Send/Receive" window. The renderer does not time blocking locally — it reads the backend write gate's snapshot (auto-sync-blocking-store.ts), so blocking clears when the backend says so rather than on a renderer-side timer.