Feature: Scheduler Refactor - Jobs Store, Separation of Concerns, and Jobs View

[m3nu]

Summary

Refactor Vorta's scheduler to improve reliability, maintainability, and user visibility into scheduled and past jobs.

Goals

1. Add Persistent Jobs Store

Current state: EventLogModel only tracks executed jobs. Pause states and pending schedules are stored in-memory and lost on restart.

Goal: Add a database model to track:

• Pending/scheduled jobs (survive restarts)
• Skipped jobs with reasons (audit trail)
• Link between scheduled intent and execution results

2. Separate Scheduling, Execution, and State Management

Current state: VortaScheduler (532 lines) handles scheduling, execution triggering, and state management in one class with manual lock management and interleaved post-backup tasks.

Goal: Split into focused components:

• Scheduling: Calculate next run times, manage timers
• Execution: Create jobs, queue them, handle results, coordinate post-backup tasks
• State: Pause/resume persistence, job status tracking, crash recovery

3. Add Jobs View UI

Current state: Log page only shows past jobs. No view of pending jobs or filtering options.

Goal: New Jobs page showing:

• Pending (scheduled) and completed jobs in one view
• Filtering by profile, repository, job type, and status
• Skip reasons for jobs that didn't run
• Ability to cancel pending or re-queue failed jobs

4. Improve Reliability

Current issues:

• QTimer 32-bit limitation (~24.8 days) with imprecise workaround
• Race conditions between job checks and submission
• Post-backup tasks not guaranteed sequential
• DBus sleep/resume detection fails silently

Goal: More reliable scheduling that handles edge cases gracefully.

Out of Scope

• Cron expression support (e.g., "weekdays at 9am")
• Job dependencies/chaining
• Retry policies for failed jobs

Open Questions

1. Should the Jobs view replace the existing Log page or be a separate tab?
2. What filtering options are most important?
3. How should crash recovery handle jobs that were running when the app crashed?

Related Files

Key files that will be affected:

• src/vorta/scheduler.py - Current scheduler (to be refactored)
• src/vorta/store/models.py - Add new job model
• src/vorta/borg/jobs_manager.py - Job queue management
• src/vorta/views/schedule_tab.py - Add Jobs page
• src/vorta/views/log_page.py - Existing log view

[khadejaa23]

Hi @m3nu,
I’m a backend-oriented engineer with a strong interest in software architecture, and I’m very interested in tackling the Scheduler Refactor (#2360) for GSoC 2026.
This project aligns perfectly with my focus on system design and persistent state management. To ensure my approach meets the project's standards, are there any smaller, related issues you’d recommend I start with to better familiarize myself with the current scheduler and database implementation, I’d really appreciate your guidance.

[false200]

Hi m3nu, I’ve opened #2438 as an initial Phase 1 contribution for #2360, focused on the persistent jobs store foundation for scheduled backups by adding a JobModel, persisting scheduled backup intent, recording skipped jobs with reasons, and linking scheduled execution results back to the stored job record.

[false200]

@khadejaa23, you mentioned interest in working on the scheduler refactor earlier.
I’ve opened PR #2438 implementing the initial persistent jobs store (JobModel + scheduled backup intent persistence) as a first step toward #2360.

Are you planning to work on the same part of the refactor as well?

[khadejaa23]

@khadejaa23, you mentioned interest in working on the scheduler refactor earlier. I’ve opened PR #2438 implementing the initial persistent jobs store (JobModel + scheduled backup intent persistence) as a first step toward #2360.

Are you planning to work on the same part of the refactor as well?

Thanks for reaching out and for the update on #2438!

Since you’ve already started with the persistent jobs store (JobModel), I’ll make sure to review your PR to stay aligned. To avoid any conflicts, I’ll focus on a different part of the scheduler refactor within #2360

[khadejaa23]

Since it’s still in the early stages and hasn't been merged yet, I’d like to collaborate on this part.

I’ll review your implementation of JobModel and perhaps suggest some enhancements or start working on the logic that connects this store to the actual scheduling triggers. This way, we can ensure the foundation is solid before moving fully into the rest of #2360.

[false200]

Since it’s still in the early stages and hasn't been merged yet, I’d like to collaborate on this part.

I’ll review your implementation of JobModel and perhaps suggest some enhancements or start working on the logic that connects this store to the actual scheduling triggers. This way, we can ensure the foundation is solid before moving fully into the rest of #2360.

Sounds good. Feel free to review the PR and suggest any improvements if you spot something that could make the JobModel or persistence layer stronger.

[false200]

The remaining parts I planned for #2360 include separating scheduler responsibilities, improving the execution and recovery flow, adding restart/crash recovery, refining timer and wake/network handling, and later introducing the Jobs UI along with broader hardening and tests.

Since you mentioned working on the logic that connects the store to the scheduling triggers, that would fit naturally as the next step once the persistence layer is in place.

[false200]

Hi @khadejaa23, since the workload and architectural considerations for this part are quite large, it might be better if you implement it from scratch as part of the full scheduler refactor.

I’ve closed the PR I opened since it tries to cover multiple parts at once and might be harder to review or could potentially introduce loopholes. Feel free to go ahead and develop it as part of the refactor.

[khadejaa23]

Thank you for the update! I appreciate the trust. I agree that keeping the PRs focused will make the review process much smoother and avoid architectural loopholes.

[false200]

Thank you for the update! I appreciate the trust. I agree that keeping the PRs focused will make the review process much smoother and avoid architectural loopholes.

Great, sounds good! Have you started working on the initial parts yet?