fix(agent): complete automation runs after end_turn

[annikaschmid]

Problem

Automation-triggered background runs on us.posthog.com can answer successfully and log Initial task message completed {"stopReason":"end_turn"}, but the task run remains non-terminal.

Because TaskAutomation.last_run_status collapses every non-terminal run to running, the automation UI stays stuck on Running even after the answer has already been delivered.

Root cause

AgentServer only explicitly updates task run status for error stop reasons. On successful end_turn it relays the answer, but it never patches the run to completed, so automation runs can remain open until inactivity timeout or another external completion signal.

Fix

• detect automation-triggered runs via taskRun.state.automation_id
• after a successful initial or resume end_turn, relay the response as before and then patch the run to completed
• leave non-automation background runs unchanged so they can still accept follow-up turns

Why this is needed

Automations are one-shot scheduled/manual executions, not ongoing chat sessions. Once an automation has produced its final answer, the backend should move it to a terminal state immediately so downstream surfaces report Success instead of being stuck on Running.

Validation

• pnpm exec vitest run src/server/question-relay.test.ts
• pnpm exec tsc --noEmit
• pnpm exec biome check packages/agent/src/server/agent-server.ts packages/agent/src/server/question-relay.test.ts

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/agent/src/server/question-relay.test.ts:554-667
**Parameterise these two test cases**

The team convention is to always prefer parameterised tests (`it.each`), and the two new cases share nearly identical setup — they only differ in the `state` value returned by `getTaskRun` and the resulting assertion on `updateTaskRunSpy`. Leaving them as separate `it` blocks duplicates ~50 lines and makes future maintenance harder. A single `it.each` over `[{ state: { automation_id: "automation-1" }, expectCompleted: true }, { state: {}, expectCompleted: false }]` (or similar) would express both behaviours without repeating the session-setup scaffolding.

### Issue 2 of 2
packages/agent/src/server/question-relay.test.ts:667
**Resume path not covered by tests**

`maybeCompleteAutomationRun` is called in both `sendInitialTaskMessage` and `sendResumeMessage` (lines 1279-1280 in `agent-server.ts`), but only the initial path is tested. A bug in the resume path — e.g. `taskRun` being `null` or the run already being in a terminal state — would go undetected. Adding at least one test that calls `sendResumeMessage` with an automation `state` would fully express the intended contract.

_{Reviews (1): Last reviewed commit: "fix(agent): complete automation runs aft..." | Re-trigger Greptile}

[greptile-apps]

_{Reviews (2): Last reviewed commit: "test(agent): address automation run revi..." | Re-trigger Greptile}