Sign up
View stargazersSign up

Pi tasks stay running when an input handler consumes a plain prompt#28792

opened10d agobyCChinoman10

Problem

A Pi task can stay marked Running even though Pi consumed its first prompt and did not start any work. I observed a delegated task remain in this state for about 103 minutes, until it was cancelled.

An extension input handler can legitimately return { action: "handled" }. Pi 1.4.0 then replies:

json
1{"type":"response","command":"prompt","success":true,"data":{"disposition":"handled"}}

No run started, so there is no agent_settled event to wait for. A following get_state reports isStreaming:false.

Reproduction

Load this minimal Pi extension, then send a plain (non-slash) prompt through T3's Pi provider:

ts
1export default function (pi) {
2 pi.on("input", (_event, ctx) => {
3 ctx.ui.notify("Synthetic guard: input consumed.", "warning");
4 return { action: "handled" };
5 });
6}

The original trigger was a specialist guard refusing incompatible settings, but that addon is not needed to reproduce the protocol behavior.

I verified the minimal extension in a fresh temporary Pi profile without credentials or model calls: handled response, idle state, zero agent/tool starts and zero agent_settled events. The live T3 incident was on 0.1.4; source inspection shows the same response-handling gap at main 3fd2b855c5c6b9169cdfe3733b34011c1c5ed4b7. I have not run a fresh end-to-end T3 reproduction on main yet.

Cause and expected result

In packages/provider-pi/src/server/adapter.ts, successful prompt responses do not inspect data.disposition. T3 probes for idle completion only for slash-command prompts or certain adopted-wake cases. A plain prompt consumed by an input handler misses that path and cannot finish.

Please use the existing idle-aware completion path for handled prompt responses too. This should retain turn ownership and protect any work an extension starts separately; it should not force-complete an active run or a handled steer.

Related to #16846, but distinct: that issue describes a probe that does not re-arm. Here the first probe is never scheduled.

Prepared with GPT-6.1 Sol in Pi/T3 Code; independently reviewed.

WWout Stiens2d ago

Note

🤖 GPT 6.1 Sol responding on behalf of StiensWout

The maintainer is retaining #28798 instead of our independent #33329, citing its broader regression coverage. Please retry the minimal input handler on a build containing the retained fix, and close this issue if the task finishes correctly after that fix lands. Our PR passed CI but received unresolved CodeRabbit feedback about pending steer acknowledgements and out-of-order prompt-response ownership, so it should not be treated as ready to merge.

CChinoman102d ago
Synced from GitHub

I can verify/vouch the (original/older) PR works because it was initially developed on a build where the bug was found and replicated, and we pushed the PR after we had verified the fix worked on our build... so we're just waiting for the maintainer's approval to merge so it becomes part of the official release and we no longer have to keep a patched build (for this specific issue/PR at least).