fix(server): launch persisted polling sync job

[GautamSharma99]

fix #830

Summary

• Retain the GenerationJob returned by the polling fallback upsert.
• Launch the background executor using the persisted job ID.
• Add a regression test covering repository divergence, persisted job metadata,
  and executor invocation.

Problem

When the polling fallback detected that a repository's HEAD differed from its
last synchronized commit, it created and committed a pending generation job.

The returned job object was discarded, but the scheduler subsequently attempted
to call execute_job(job.id, app_state). This raised a NameError, which was
caught by the scheduler's outer exception handler.

As a result:

1. The pending job remained in the database.
2. No background sync was launched.
3. Subsequent polling runs skipped the repository because an active pending job
   already existed.

Fix

Store the result of upsert_generation_job() in job and use its persisted ID
when launching the background task.

Testing

• Added test_polling_fallback_launches_persisted_job.
• Verified the persisted job status and polling configuration.
• Verified that the executor receives the persisted job ID.
• Changed files pass Ruff formatting/linting and mypy.
• All JavaScript lint, type-check, unit, and VS Code smoke tests pass.

Verification note: the full Python run reached 7,484 passed, 14 skipped. Two unrelated code-rationale tests fail independently on the existing
branch. Thirteen initially sandbox-sensitive failures passed when rerun outside the sandbox. Repository-wide Ruff/format/mypy also report
substantial pre-existing issues, while both changed files pass their focused checks.

[repowise-bot]

✅ Health: 7.6 (unchanged)

📋 At a glance
1 hotspot touched · 1 new finding introduced. Scoped to packages.

🔎 More signals (1)

🔥 Hotspot touched (1)

• .../server/scheduler.py — 0 commits/90d, 1 dependents · primary owner: Raghav Chamadiya (100%)

---

📊 Full report · ⭐ Star Repowise · 📥 Install bot · Last updated 2026-07-14 12:54 UTC
_{Silence on a single PR with [skip repowise] in the title · Per-repo toggle on repowise.dev/settings?tab=bot}

[RaghavChamadiya]

The one-line fix is correct. upsert_generation_job returns the persisted GenerationJob, so job.id on the launch line is now defined, which clears both the NameError and the F821. The added test is a real regression test: on the current code the NameError is swallowed by the outer except before execute_job is ever awaited, so assert_awaited_once() would fail without the fix.

Two things to sort out before merge:

1. This overlaps PR fix(server): offload blocking git operations #833. fix(server): offload blocking git operations #833 (offloading blocking git) also includes this exact job = await crud.upsert_generation_job(...) change on scheduler.py, and both branch off main. Whichever lands first, the other will conflict on that line. Let's decide which PR carries the fix and drop it from the other, or stack fix(server): offload blocking git operations #833 on top of this one, so we don't merge the same change twice.

2. Scope vs [Bug] Polling fallback leaves sync job pending after undefined job error #830. This resolves the specific NameError path, but the issue's "Ideally" section is left open: the scheduler still hand-rolls its own task launch (scheduler.py:160-170) instead of reusing _launch_job_task in repos.py. As a result a poll-launched sync is not registered in app.state.job_tasks (the cancel endpoint can't reach it), and if execute_job fails in a way it can't self-record, the job stays pending and re-wedges the repo behind the active-job guard, which is the same stuck-pending class of bug this issue is about. The two suggested regression tests for that (task-launch failure moves the job to failed; a second polling pass doesn't duplicate an active job) aren't covered here either.

Fine to merge this as the targeted crash fix, but let's not close #830 on it. Suggest routing the scheduler through the shared managed-launch path in a follow-up so it gets the same cancellation and failure-marking as the REST path