Request Tracker Triage

Trigger DAIV automatically whenever a new ticket lands in Request Tracker. The DAIV agent reads the ticket, performs triage (bug / config / how-to / unclear) and — when the ticket is code-related — a root-cause analysis against the queue's repository. The report is posted back to the ticket as an internal comment (staff-only, not emailed to the requester).

The whole integration is a single RT Scrip. No bridge service, no webhook receiver, no polling.

How it works

RT ticket Create
      │
      ▼
RT Scrip (Perl, "On Create", applies to allow-listed queues)
   1. Resolve queue → repo_id
   2. Build prompt (ticket id, url, queue, subject)
   3. POST $DAIV_URL/api/jobs
      │
      ▼
DAIV agent runs asynchronously
   - Reads the full ticket via its RT MCP tool
   - Does triage; if code-related, performs RCA against the repo
   - Posts the report as an internal comment on the ticket via RT MCP

The Scrip is fire-and-forget: it submits the job with a 5-second socket timeout and a 10-second hard wall-clock ceiling (via alarm), and any die from the HTTP client or JSON parser is trapped in eval. A DAIV outage — including DNS failure or a malformed response — never blocks or aborts the ticket-create transaction.

Prerequisites

• A DAIV deployment reachable from the RT host, with the Jobs API enabled.
• The RT MCP server wired into the DAIV agent (see MCP Tools). The RT MCP must authenticate as a user with rights to comment on the target queues. A dedicated daiv-bot RT user is recommended so comments are clearly attributed.
• A DAIV API key for a dedicated service user:

python manage.py create_api_key rt-triage --name rt-scrip

Store the emitted prefix.secret string; it cannot be retrieved later.

Configure RT

1. Add the DAIV endpoint and key to RT_SiteConfig.pm

Set($DAIV_URL,     'https://daiv.example.com');
Set($DAIV_API_KEY, 'prefix.secret');

Reload RT after editing: apache2ctl graceful (or whichever reload command your RT host uses).

2. Install the Scrip

1. Open Admin → Scrips → Create in the RT web UI.
2. Fill the form:

Field	Value
Description	DAIV triage on create
Condition	On Create
Action	User Defined
Template	Blank
Stage	TransactionCreate
Applies To	(leave empty for now — configured in step 3)

1. Put return 1; in the Custom action preparation code field and paste the body of rt-daiv-triage.scrip.pl into the Custom action cleanup code field. Leave Custom condition empty. Save. (Cleanup runs after the ticket transaction is committed, so the agent can load the new ticket via the RT MCP.)

2. Edit the %QUEUE_REPO_MAP hash at the top of the pasted code so each queue you care about maps to the correct DAIV repo_id (e.g. group/project).

3. Attach the Scrip to queues

From the Scrip's Applies To tab in the RT admin UI, select the queues you want triaged. The "Applies To" list and the keys of %QUEUE_REPO_MAP must stay in lockstep — any queue where the Scrip runs but no repo is mapped will log a warning and skip (no ticket change, no job).

Start with a single pilot queue. Expand only after the pilot looks healthy.

Verify the pilot

1. File a test ticket in the pilot queue.
2. tail -f /var/log/request-tracker4/rt.log (or your RT log path) — look for:

daiv-triage: submitted job <uuid> (batch <uuid>) for ticket <id> (queue=... repo=...)

1. Open the DAIV Sessions page and confirm a new API Run session exists for the target repo.
2. Within a minute or two, an internal comment with the triage report should appear on the ticket. If it doesn't, check the session detail page — the agent may have errored mid-run or failed to post via the RT MCP.

Troubleshooting

Symptom	Likely cause	Fix
No log line at all after ticket create	Scrip not attached to the queue, or condition/stage is wrong	Re-check the Scrip's Applies To list and confirm Condition=On Create, Stage=TransactionCreate
DAIV_URL or DAIV_API_KEY not set in rt.log	RT_SiteConfig.pm not reloaded	apache2ctl graceful
queue '<name>' in Applies-To but missing from QUEUE_REPO_MAP	"Applies To" and the inline map drifted apart	Add the queue to %QUEUE_REPO_MAP with its repo, or remove it from "Applies To"
failed to submit job … 401	Wrong or expired DAIV API key	Rotate via python manage.py create_api_key and update RT_SiteConfig.pm
rate-limited for ticket … 429 (warning)	Jobs API rate limit exceeded (default 20/hour per user)	Raise the jobs throttle rate in Site Configuration (jobs_throttle_rate), or use a separate API-key user per queue. Logged at warning — safe to alert on error only
failed to submit job … <non-2xx, non-429>	DAIV returned 4xx/5xx other than rate-limit	Check the DAIV sessions list and access log; the status line + body are captured
exception in triage scrip: daiv-triage timeout	The 10-second hard ceiling tripped — usually DNS resolution or a stalled TLS handshake	Check DNS/network from the RT host to $DAIV_URL; confirm cert chain if using HTTPS
exception in triage scrip: <other>	Unexpected die from LWP, the RT ticket object, or elsewhere	Inspect rt.log around the timestamp; the captured $@ will point at the source
Job completes in DAIV but no comment on the ticket	RT MCP auth user lacks comment rights on the queue, or MCP call errored	Grant the MCP's RT user the CommentOnTicket right on the queue; inspect the run's tool calls in the session detail

Cost considerations

The Scrip requests high reasoning effort by submitting agent_thinking_level: high — which applies high effort to the system default model. This produces better triage but is more expensive. To force the most capable model (rather than the default), also pass an explicit agent_model (e.g. the Opus spec). See the agent-override fields on the Jobs API page. For high-volume queues, consider:

• Lowering or omitting agent_thinking_level in the Scrip body for a cheaper first pass — the system default model then runs at its default effort.
• Adding a queue-level rate limit via a separate DAIV API-key user with a lower jobs_throttle_rate (Site Configuration).

Files

• rt-daiv-triage.scrip.pl — pasteable Scrip body.