discord-manager: Skill for Claude Code

Background jobs

Everything here documents the repository as it is on main. If main disagrees with this file, main wins: follow it and flag the drift.

There is no queue server, no worker process, and no jobs table. app/framework/scheduler.server.ts is the entire scheduler: one in-memory FIFO queue, one job running at a time, inside the ingest daemon. Jobs are declared next to the domain logic they drive in app/business/, listed in app/business/jobs.server.ts, and run by the one runner app/ingest/run.ts builds.

The runtime, stated

Design against these facts, not against habits from a durable queue.

• One queue, one job at a time. createSchedulerQueue holds a pending array and a drain loop that awaits each invoke() before shifting the next task. Two jobs never overlap, and a slow job holds everything behind it.
• The queue is process-global, held by getOrSetGlobal('schedulerQueue', createSchedulerQueue). Every makeJob in the process shares it, registered or not.
• Only the ingest daemon drains it. app/ingest/run.ts is the sole caller of makeSchedulerRunner(jobs) and scheduler.start(). An enqueue on a path the MCP server reaches pushes onto a queue that process never starts, and the work simply waits forever.
• Enqueueing before start() is fine — tasks accumulate and run once the runner starts.
• Nothing survives the process. The queue is memory only. A task still waiting at shutdown is gone, and there is no dead-letter row to find it in later.
• makeCronJob takes an interval in milliseconds, not a cron expression: start() opens one setInterval(job.tick, job.intervalMs) per registered job that has both, and each tick enqueues the job with an undefined payload.
• Retries are thrown-error only. Defaults are maxAttempts: 5 and retryDelayMs: 250; attempt n waits retryDelayMs * 2 ** (n - 1). The wait happens inside the drain loop, so a backing-off job blocks every other job, and the retry re-enters at the tail of the queue.
• The cap is a drop. Past maxAttempts the loop writes Job "<name>" gave up after N attempts to console.error and moves on. Nothing else records that the work never happened.
• dedupe collapses only what is still waiting. With { dedupe: true }, an enqueue is skipped when another task with the same job name is already in pending. The task currently running has been shifted off pending, so dedupe never suppresses an enqueue that arrives while an identical job is mid-flight. Default is false.
• stop() is graceful. It clears the interval timers, stops the loop from picking up new tasks, and awaits the job already running.