Skip to content

Persistent Job Queue & Maintenance Worker for backend #367

Open

Description

@its-me-abhishek

Is your feature request related to a problem? Please describe.
The current job queue is volatile. If the backend container crashes or restarts, all queued tasks are lost forever. This needs to be persistent, so that occasional backend downtimes do not affect the Jobs. Additionally, as we implement persistence, we need a way to manage the lifecycle of the "Success" and "Failure" logs stored in the database to prevent unbounded disk usage.

Describe the solution you'd like

  1. Implement a disk-backed queue using bbolt (or something similar, open to suggestions) and an internal Go-based cron scheduler for maintenance.

    • The Queue will work as a database that will store all Jobs from the JobStore.
  2. Persistence Layer (bbolt)

    • Store the database file at /app/data/queue.db to use the existing Docker volume.
    • Job States: Implement buckets or tables for Pending, In-Progress (doubt if it should exist, perhaps Pending, Completed, and Failed should suffice for our use case), and Completed statuses.
    • Reliability: On startup, a NewJobQueue function must scan the Pending and In-Progress buckets and re-insert those jobs into the channel. Upon completion, mark them as completed.
  3. Scheduled Maintenance (Cron)

    • Integrate a package like robfig/cron/v3 to handle periodic tasks without external dependencies.
    • Cleanup Job: Runs every 24 hours (or at midnight). Add that CRON parameter as an optional variable in .env file. Users might want to customise, but having a default value is nice, as well.
    • Logic: Deletes all entries from the Completed or Failed buckets that are older than 7 days.

Additional context
Need to take into account the amount of storage that database will cost. And hence optimise it further. Documentation, related to the changes, related to env vars, and cron job along with the Database need to be added, to the Backend README. The current functionality should not be affected/broken.

  • The issue is open to all for their versions of implementations.

Links:
https://github.com/etcd-io/bbolt
https://github.com/robfig/cron

Activity

  1. Hell1213 commented on Jan 3, 2026

    @Hell1213
    Contributor

    hey @its-me-abhishek , I'm working on this issue and will open PR soon .

  2. added a commit that references this issue on Jan 6, 2026
    95da0ee
  3. added 2 commits that reference this issue on Jan 15, 2026
    394abd4
    223af79
  4. HarshRaj29004 commented on Jan 22, 2026

    @HarshRaj29004
    Contributor

    Hi @its-me-abhishek can i work on this?

  5. added a commit that references this issue on Jan 24, 2026
    28ae700
  6. RohitSutar1823 commented on Nov 1, 2026

    @RohitSutar1823

    Hi @its-me-abhishek, @Hell1213, @HarshRaj29004 — I'm interested in this issue. I've read backend/controllers/job_queue.go on current main: the queue is an in-memory chan Job (buffer 100), and Job holds an Execute func() error closure, so jobs can't be written to disk as they are.

    Before writing anything, a few questions:

    1. @Hell1213 — you said in January you were working on this. Is that still active? I don't want to duplicate your work, and I'm happy to help or review instead.
    2. @its-me-abhishek — would you prefer I change jobs into serializable records (a job type plus a payload), with a handler registered for each type? That would touch all the controllers that call AddJob.
    3. Is bbolt still your preferred store?
    4. On restart, should jobs that were in progress be retried or marked failed? I need to check whether the Taskwarrior operations are safe to run twice.
    5. The payloads come from request bodies. Are there any credentials or secrets in them that shouldn't sit in a plaintext queue.db?
    6. PR fix(tw): isolate Taskwarrior data with TASKDATA and serialize CLI ops #474 also changes how jobs run. Should this wait until that is merged or closed?

    I'll wait for your go-ahead before opening a PR. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendSomething isn't working on the backendcomplexenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions