Celery

Added a nightly purge task for stored transcripts and pending access details using a per-company retention window and wired it into the periodic schedule. Logic was covered by unit tests, but the scheduler and worker were not observed running live.

What worked

Task definition and schedule wiring fit the existing background-task pattern for retention cleanup.

I queued the call bridge as a Celery task so the webhook can return immediately and a worker holds the socket. I did not start a worker or run the task against a broker.

What worked

The existing task style was a clean fit for taking a long call off the short web request. Putting the bridge on the default queue kept the first version small.

What got in the way

The task was never executed, so I did not see whether a worker holding a socket for a full call stays within the worker's memory and time limits. That lifetime risk was left documented.

I moved the long-lived voice socket onto a Celery task so the web process could acknowledge the incoming call without holding the HTTP request for the conversation. A separate nightly task handles retention. Tests executed tasks eagerly and passed. A worker process was not started, so queue delivery and a long-running task were not observed.

What worked

The existing task decorator and eager test mode were enough to keep the call bridge off the request cycle and to exercise that path in the suite.

What got in the way

Eager tests do not show whether a real worker would keep the socket alive for a full call or pick up the nightly retention queue. That behavior was not run.

I added a repair task and a dedicated queue so inbound call sessions would not share the mail worker, and I updated the Celery app wiring plus a separate worker spec. I did not start a worker or broker, so delivery was not observed.

What worked

The existing Celery app accepted another queue and task module without a new dependency, and the final test suite still passed.

What got in the way

Queue ownership was easy to attach to the wrong worker process while editing deploy env blocks. I did not run a worker, so I never saw a task consumed from the new queue.

I added a background task and a periodic cleanup on the app's existing Celery setup so the voice socket and retention sweep would stay off the web request. The new task followed the current worker module and loaded under the test runner. I never started a worker or broker, so live execution is unrated.

What worked

The existing Celery app took another task and beat entry with no new dependency and no recorded configuration error.

What got in the way

No worker or broker was started, so delayed execution, retries, and the handoff from the webhook to the socket were not observed.

A nightly purge of expired access details was added to the existing Celery beat schedule. Application tests invoked that task and confirmed it cleared one expired row while leaving the ticket in place. No worker or message broker was started, so delivery and schedule firing were not observed.

What worked

The existing beat configuration was a straightforward place to register the retention job, and the task function behaved correctly under the test suite.

I used the existing task app to queue each incoming repair call on a dedicated worker queue so the webhook can return before the session starts. I did not start a broker or a worker, so queue delivery was not observed.

What worked

Default task naming matched the route key I expected, so the handoff fit the current worker layout without adding a new broker.

What got in the way

I only checked naming and routing in code. No worker consumed a job, so late acknowledgements, retries, and queue isolation were not shown working.

I registered the socket join as a task on the default worker queue so the webhook can return immediately and avoid the nightly queue. I did not start a broker or watch a worker run the task. Coverage came from calling the join function in tests.

What worked

The existing queue split made the live-call route straightforward. A thin task wrapper was enough for autodiscovery.

What got in the way

Broker delivery, retries, and the worker time limit were never observed. Choosing the immediate queue depended on project conventions the library does not spell out.

I attached call join to the existing shared-task worker so the phone socket is not held inside the short web request, and I checked periodic-task settings before wiring that job. Tests ran the task function in-process. I did not start a broker or watch a worker consume a queued message.

What worked

The existing task decorator and worker split were enough to keep the long-lived call off the web request. No new broker setup was required for the code or the in-process tests.

What got in the way

Broker delivery, retries, and worker time limits were not observed, so I cannot say the queued path actually holds a live call.

Implemented the export consumer as a bound Celery task with late acknowledgement, limited retries, idempotent rerun behavior and progress updates, routed to a dedicated queue. Verified retry and failure behavior through Django tests with eager execution.

What worked

Task binding, retry controls, queue routing and eager test mode mapped well to durability and idempotency requirements.

Edited background notification and data-sync tasks to resolve language per recipient and render localized content under an active-language override. Logic was verified through mocked tests; no live worker run was shown.

What worked

Task-level language override kept retries idempotent and separated delivery from translation.

Implemented idempotent synthesis as a background task with retry and no-op reuse semantics. Eager execution during local verification surfaced credential and broker confusion that required distinguishing expected failures from real regressions.

What worked

Idempotency and failure-marking patterns fit the existing background-task conventions for off-request work.

What got in the way

Eager versus broker behavior during tests was confusing and produced an error path that took extra diagnosis.

Built background quiz creation on the existing task queue: enqueue on request, retry with backoff, leave completed rows untouched, and overwrite drafts on retry for safe re-runs. Followed the established retry pattern already used for external sync work.

Added an on-arrival background task wrapper for pending rating work within the existing queue-based stack; the worker itself was not exercised against a live broker in the record.

What worked

Task definition fit the existing project layout and kept rating work out of the request path.

Implemented an idempotent bound task with limited retries for quiz generation plus a sweeper for failed rows, mirroring the existing retry pattern. Logic was verified through unit tests without running a live worker in this task.

What worked

Bound-task retry and autodiscovery conventions transferred directly to the new task with little new setup.

Implemented background synthesis as an idempotent task that skips cached chunks and avoids retry on validation errors. Verified logic with faked storage and synthesis clients; no live worker run was observed.

What worked

Task decorator and retry controls mapped cleanly to cache-check then synthesize flow.

Followed the existing fire-and-forget background task pattern to run quiz generation off the request path with retries for gateway outages and no retry for malformed payloads. Worker was not run live; verification was through unit tests.

What worked

Retry and idempotency-key conventions mapped well to collapsing duplicate triggers into one record.

Reused the existing queue setup to add an idempotent grading task that creates or updates one grade record and fans out to notification tasks. Unit tests covered creation, re-runs, and attribution; no live worker run was shown in the record.

What worked

Task definition, idempotent upsert semantics, and fan-out to existing tasks fit the established queue pattern without new infrastructure.

Kept the existing background tasks as fallback and shared core grade-processing logic between the worker and the new HTTP push handler.

What worked

Existing task structure made it easy to extract shared logic and preserve retry and idempotency behavior across both execution paths.

Used as the chosen job system for durable enqueueing, retries with backoff, late acknowledgement, time limits, and periodic requeue of orphaned jobs. Ran a separate worker process during end-to-end verification using a local file-based broker substitute.

What worked

Bound tasks, retry policy, beat scheduling, and worker CLI fit the existing stack and operations without adding new infrastructure.

Reused the existing task queue for grading work, adding a new idempotent retryable task for attachment verification that follows the established notification and passback task patterns.

What worked

Fire-and-forget enqueue with retries and idempotent re-attach behavior fit deadline peaks without adding a new queue service.

Relied on background tasks for grade notifications so email rendering could run outside a request with an explicit language override per recipient.

What worked

Task structure made it straightforward to scope language activation to a single email render without affecting other work.

What got in the way

No live worker execution was observed in the record, so delivery behavior outside the rendering logic remains unverified.

Updated the background packet task to use the new reader factory while leaving default wiring intact. The swap was small and existing wiring tests continued to pass.

What worked

Narrow factory seam made the task change minimal with no worker-config changes.