fix(site): only show active tasks in waiting for input tab #20933
Conversation
| }); | ||
| const idleTasks = tasksQuery.data?.filter( | ||
| (task) => task.current_state?.state === "idle", | ||
| (task) => task.current_state?.state === "idle" && task.status === "active", |
There was a problem hiding this comment.
An alternative solution is handling this on the backend instead and unsetting current state. Thoughts?
This is probably good enough for now though.
Edit: On second thought, I'll give the BE approach a try.
There was a problem hiding this comment.
I think I prefer the frontend approach here. The backend should just return the real data, if the task has a state, we should send it. Different parts of the UI (or other clients) might want to use that state differently, so it makes more sense for the FE to handle the filtering, rather than having the BE selectively return the field.
There was a problem hiding this comment.
Yeah, after trying the alternative approach I agree, I'll revert to the original solution. 👍🏻
There was a problem hiding this comment.
That said, I think the task state would need a different type or some change to better reflect the state. I don't think idle makes sense for a stopped task, even if that's the last app state the workspace had.
For now, though, the FE approach will suffice.
9b24954 to
b3b3929
Compare
b3b3929 to
3c84902
Compare
47dd436 to
4bd500d
Compare
4bd500d to
e528432
Compare
ssncferreira
left a comment
There was a problem hiding this comment.
LGTM, just a small nit
| spyOn(API, "getTasks").mockResolvedValue([ | ||
| { | ||
| ...firstTask, | ||
| id: "active-idle-task", |
There was a problem hiding this comment.
IIUC, the preferred method for these GET endpoints mocks is something like:
parameters: {
queries: [
{
key: ["tasks", { owner: MockUserOwner.username }],
data: [
{
...firstTask,
id: "active-idle-task",
display_name: "Active Idle Task",
status: "active",
current_state: {
...firstTask.current_state,
state: "idle",
},
},
...
],
},
{
key: getTemplatesQueryKey({ q: "has-ai-task:true" }),
data: [MockTemplate],
},
],
},
There was a problem hiding this comment.
I believe most of this file should be converted, doesn't feel appropriate to do it in this PR, or to introduce mixed usage. 🤔
There was a problem hiding this comment.
Unfortunately, I think we already have mixed usages in a lot of files, as this is something that I was already called out on in other PRs as well, and I only updated the stories I was changing 😞 I'm ok with addressing this in a separate PR 👍
DanielleMaywood
left a comment
There was a problem hiding this comment.
We should have a follow-up PR to address the spyOn issue @ssncferreira raised
@DanielleMaywood I can start a mux for this, but in principle, this PR didn't introduce the |
| spyOn(API, "getTasks").mockResolvedValue([ | ||
| { | ||
| ...firstTask, | ||
| id: "active-idle-task", |
There was a problem hiding this comment.
Unfortunately, I think we already have mixed usages in a lot of files, as this is something that I was already called out on in other PRs as well, and I only updated the stories I was changing 😞 I'm ok with addressing this in a separate PR 👍
Summary
Fixes the issue where stopped or errored tasks were incorrectly showing in the "Waiting for input" tab on the TasksPage.
Root Cause
The frontend was filtering tasks by checking only if
current_state.state === "idle". This caused tasks withstatus === "paused"orstatus === "error"to still appear in the "waiting for input" tab if they had an idle state.Solution
Updated the filter to check both:
current_state.state === "idle"task.status === "active"This ensures only running tasks that are actually waiting for user input are shown in the "Waiting for input" tab.
🤖 This change was initially written by Claude Code using Coder Tasks, then reviewed and edited by a human 🏂