fix: run blocking verify calls in threadpool

[asnaassalam]

Before opening: make sure there is an issue tracking this work, and link it below. PRs without a linked issue may be closed without review.

Linked issue

Closes #224

What this PR does

The /verify endpoint called verify_repo() and _scan_repo_dir() directly inside an async route. Both are blocking (synchronous) calls, so they occupied the single event loop for their full duration freezing all other requests until verification finished. This PR wraps both calls in run_in_threadpool so they run in a separate thread instead of blocking the main event loop.

Type of change

• Bug fix
• New feature
• ML model / training pipeline
• Refactor (no behaviour change)
• Documentation
• Tests only

ML tier (if applicable)

• Tier 1 — Triage
• Tier 2 — Predictive
• Tier 3 — Autonomous
• Not ML-related

Stack affected

• Backend
• Frontend
• Both

---

Changes

Backend

• Wrapped verify_repo(repo_dir) call in run_in_threadpool.
• Wrapped _scan_repo_dir(...) call in run_in_threadpool using functools.partial, following the same pattern already used elsewhere in main.py (e.g. the scan endpoint).
• No change to the internal logic of either function, only how they're invoked.

Frontend

• No frontend changes.

New dependencies

• None. run_in_threadpool is part of FastAPI, already a dependency, no new package added.

Database / schema changes

• None

---

Testing

How did you test this?

• Temporarily added time.sleep(10) inside verify_repo to simulate slow verification.
• Ran the server locally and called /verify via /docs.
• While /verify was still running (~10-12 seconds), fired a second unrelated request (/docs) in a separate tab and confirmed it responded instantly instead of waiting, proving the event loop stayed free.
• Removed the temporary sleep before pushing.
• Re-tested /verify normally to confirm it still returns a correct 200 OK response.

Checklist

• Tested locally end-to-end (upload ZIP or GitHub URL → scan → findings returned correctly)
• New ML model falls back gracefully when model file is absent
• No new console.error or unhandled Python exceptions introduced
• Added or updated tests where applicable
• requirements.txt / package.json updated if new dependencies added
• New model files (.pkl, .pt, etc.) are gitignored, not committed

---

Anything reviewers should focus on

Followed the same run_in_threadpool + functools.partial pattern already used elsewhere in main.py for consistency. Please confirm this doesn't introduce any thread-safety issues in verify_repo or _scan_repo_dir.

Screenshots (if UI changed)

N/A (Backend-only changes)

[github-actions]

🎉 Thank you @asnaassalam for submitting a Pull Request!

We're excited to review your contribution.

Before Review

✅ Ensure all CI checks pass
✅ Complete the PR template
✅ Link the related issue

⚡ Want faster reviews and contributor support?

Join our Discord community:

🔗 https://discord.gg/FcXuyw2Rs

Maintainers and mentors are active there and can help resolve blockers quickly.

Happy Contributing! 🚀

[github-actions]

✅ PR template check passed!

@arpit2006 this PR is ready for your review. 🚀

[Copilot]

Pull request overview

This PR fixes a scalability/performance bug in the backend by preventing the async /verify FastAPI route from executing long-running synchronous verification and scanning work on the main event loop thread.

Changes:

• Offloaded verify_repo(repo_dir) from the /verify async route into run_in_threadpool.
• Offloaded _scan_repo_dir(...) from the /verify async route into run_in_threadpool (via functools.partial), matching existing patterns in main.py.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[arpit2006]

@asnaassalam , Please Resolve CI issue!

[github-actions]

✅ PR template check passed!

@arpit2006 this PR is ready for your review. 🚀

[arpit2006]

@asnaassalam , CI issue