LumenClip Docs
LumenClip Docs
LumenClip engineering documentation
Schedule pageBackend schedulingRemindersManual publication and linking
Jobs

Backend scheduling

How background jobs, scheduled posts and reminders run on the Railway worker and the Appwrite jobs table.

Background work runs on one long-running Railway worker service that polls the Appwrite jobs table. There is no scheduler service and no Appwrite Function. Recurring automations were removed with the rendering-engine refactor; nothing generates content on a timer.

Job types

TypeEnqueued byWhat it does
render-slideshowAPI/MCP renders too large to render inlineRenders the frozen resolved spec and writes <renderId>-NN files to the renders bucket.
publish-postThe worker's minute sweep, for due scheduled posts not yet handed to SocialBuUploads the render to SocialBu and creates the post.
notifyThe worker's minute sweep, for pending in-app notifications that are dueMarks the notification delivered so it appears in the inbox.

Lifecycle

enqueue (deterministic id when deduped)
  -> jobs: queued, run_at
  -> worker claim: job_leases/<jobId>.<attempt> (409 = another worker won)
  -> jobs: running, lease renewed while the handler works
  -> succeeded | queued again with backoff | dead after max_attempts

Handlers are idempotent: a job can run again after a crash or an expired lease. Scheduled posts keep their own publish_at; SocialBu publishes at that time once the post is created there, so the worker only needs minute-level precision.

See Railway worker for operating the service.

Schedule page

Read the content calendar, understand lifecycle states, filter work, inspect items, and manage scheduled posts.

Reminders

Configure Telegram lifecycle notifications and acknowledge manually posted generations without blocking automatic publishing.

On this page

Job typesLifecycle