EasyPay Jira assignment history backfill

This post-deploy runbook backfills complete Jira assignee history for organization 38, Jira connection 46, and project ESP, then switches the existing Support dashboard to per-agent handling time. It does not deploy application code.

Cohort and duration semantics

The cohort is Jira tickets whose external_updated_at falls between a fixed scan start and ceiling, newest first. The start is three calendar months before the first run. This activity boundary deliberately includes tickets created earlier but assigned, updated, or resolved during the reporting window. For each selected ticket, the sync fetches the complete paginated Jira changelog and persists every assignment, reassignment, and unassignment event; individual events are not clipped to the three-month cutoff.

An agent’s handling time is the sum of completed assignment intervals on that conversation. Reassignments and unassignments close the preceding interval. A final open interval is excluded until a later assignment event or the ticket’s resolved or closed timestamp supplies its end. Participants who were never assigned retain NULL handling time. The metric never reads conversations.handling_time.

Start the persistent backfill

After the Rails migration and API2 code are deployed, open Admin → Maintenance tasks → Jira → EasyPay Jira assignment-history backfill. Confirm the production write and start the run.

The admin action initializes a fixed scan window and enqueues a chain of 25-ticket BullMQ jobs. Every successful ticket advances the database checkpoint. Each chunk reads that checkpoint before it starts and enqueues the next chunk after it finishes, so worker deployments repeat at most one small chunk instead of interrupting a multi-hour job.

The admin dashboard reads progress from the database checkpoint rather than from an individual BullMQ job. A five-minute watchdog enqueues the next chunk when the checkpoint is incomplete and no chunk is active, waiting, or delayed. The watchdog never starts a backfill that has not been explicitly initialized from Admin → Maintenance tasks.

The validation block reports the fixed August 24–30, 2026 creation cohort. Expected values after backfill are 1,361 cohort tickets, 89 tickets assigned to Support, and 6 distinct Support Jira identities.

Each chunk processes one ticket at a time, waits 750–1,250 ms with jitter between tickets, honors Jira Retry-After on HTTP 429 responses, and checkpoints after every successful ticket in organization_data_sources.sync_data. The cursor stores the bigint conversation ID as a string and resumes at the newest-first (external_updated_at, id) position. A failed ticket is not skipped or checkpointed; automatic retries and the watchdog continue from the last successful ticket.

After it completes, the Maintenance Task result should report completed: true; the August validation should match the expected values.

Switch the existing dashboard

infisical run --env=prod -- tsx scripts/update-easypay-support-agent-handling-dashboard.ts --write

The guarded, idempotent update changes the three existing Support dashboard widgets to conversation_agent / average / agent_handling_time. Widget 404 remains grouped by Agent, the dashboard’s existing Support team filter remains in place, and the metric also supports Team grouping in the editor. The script aborts before mutation if any exact dashboard, team, filter, or widget guard has drifted.