Skip to content

feat: allow sending follow-up prompts to a task when resuming#22302

Merged
SasSwart merged 11 commits intomainfrom
jjs/internal-1269
Mar 6, 2026
Merged

feat: allow sending follow-up prompts to a task when resuming#22302
SasSwart merged 11 commits intomainfrom
jjs/internal-1269

Conversation

@SasSwart
Copy link
Contributor

@SasSwart SasSwart commented Feb 25, 2026

Summary

This PR adds a follow-up flow for paused Tasks so users can submit another prompt as part of resuming the same task/session.

Screen.Recording.2026-02-25.at.15.17.54.mov

What changed

  • Task page UX

    • Added a new Follow-up action in paused task state.
    • Added FollowUpDialog to collect and submit follow-up input.
  • Follow-up flow behavior

    • If task is paused/stopped: call resume first, then wait for polling to observe task active, then send input.
    • Dialog closes itself after successful send.
    • Added clear error handling for:
      • resume failure
      • build failure/canceled while resuming
      • send failure
  • Stable API route parity

    • Added POST /tasks/{user}/{task}/pause and POST /tasks/{user}/{task}/resume to the stable /api/v2/tasks router block.
  • SDK alignment

    • Updated codersdk pause/resume methods to use stable /api/v2/tasks/... endpoints instead of /api/experimental/....
  • Frontend API/query alignment

    • site task pause/resume/send paths are on stable /api/v2/tasks/....
    • Updated task query helpers accordingly.
  • Storybook coverage

    • Added follow-up dialog stories for key states:
      • open dialog
      • active direct send
      • auto-resume then send
      • resuming progress visible
      • resume build failure
      • send failure
      • empty message disabled
    • Added/updated mocks for task logs and new follow-up flows.

Closes coder/internal#1269

@SasSwart SasSwart marked this pull request as ready for review February 25, 2026 13:32
@coder-tasks
Copy link
Contributor

coder-tasks bot commented Feb 25, 2026

Documentation Check

New Documentation Needed

  • docs/ai-coder/tasks.md - Document the task interaction workflow for paused tasks. This PR introduces a "Follow-up" action on the task page that lets users send a follow-up message to an existing session when resuming a paused task.

    ⚠️ Documentation was added but then removed in commit d9910aa ("remove docs for now"). Still needs to be re-added before merging.

Updates Needed

  • docs/ai-coder/tasks.md — The pause/resume endpoints were promoted from /api/experimental/tasks/... to /api/v2/tasks/... (stable). If any docs referenced the experimental paths, they would need updating. No existing docs reference the experimental task endpoint paths, so no updates needed here.

Automated review via Coder Tasks

@mafredri
Copy link
Member

Nice work @SasSwart, I haven't reviewed yet, but I looked at the video and some thoughts came to mind:

  • It's unfortunate we block the view of what's happening behind the follow-up message dialogue, I saw the view build but I'm not seeing much value in the dialogue remaining open?
  • It'd be nice if we let the follow-up be edited until it's been delivered (the user might think a-ha, let me add one thing!)
  • One option would be to dismiss the dialogue on resume & send, continue showing the follow-up button where the message can be updated

And finally, very cool seeing this work end-to-end, nice! I think until we add a proper queueing system via coderd, we should mention that refreshing or leaving the page will dismiss the follow-up message (unless I'm mistaken).

@SasSwart SasSwart requested a review from mafredri March 4, 2026 10:53
Copy link
Member

@mafredri mafredri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Core flow looks good, nice work.

One thing I noticed but did not verify by testing, once we enter the startup logs streaming starting phase, we lose access to the follow up dialogue if we've dismissed it? I think it'd make sense to show the button there as well.

r.Post("/send", api.taskSend)
r.Get("/logs", api.taskLogs)
r.Post("/pause", api.pauseTask)
r.Post("/resume", api.resumeTask)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it should be done in a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lucky for us It has since been done in a separate PR:
#22544

I'll rebase this, then the change should disappear from this PR

const taskRouteKey = `${username}/${taskId}`;
const prevTaskRouteKeyRef = useRef(taskRouteKey);
const queryClient = useQueryClient();
const resumeFollowUpMutation = useMutation({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This creates a second resume mutation independent from resumeMutation. Neither disables the other's button, so a user can fire both concurrently. Could we pass isFollowUpSending down to disable the Resume button, or unify into one resume path?

).toBeInTheDocument();
});
},
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice coverage overall. A few gaps you could consider filling:

  • resumeTask rejecting (500) during the follow-up flow (different path than build failure)
  • Error recovery: error state -> reopen dialog -> resubmit -> success

@SasSwart SasSwart force-pushed the jjs/internal-1269 branch from 6b39f93 to 2617d38 Compare March 5, 2026 11:44
Copy link
Contributor

@jakehwll jakehwll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly I'd love if the lifecycle of this was handled better 🙂 But I can see why the tradeoffs were necessary 😅

LGTM

@SasSwart
Copy link
Contributor Author

SasSwart commented Mar 6, 2026

@jakehwll

Honestly I'd love if the lifecycle of this was handled better

Could you expand on this a little? Keep in mind my skillset is a little biased towards backend work, so the trade-offs you mention might just be ignorance on my part. I'm happy to make this better if I can.

SasSwart added 11 commits March 6, 2026 12:10
- Disable Resume button when follow-up flow is in progress to prevent
  concurrent resume requests.
- Add 'sending' stage to early-return guard in queueFollowUp to prevent
  re-triggering the resume flow while already sending.
- Use task?.status instead of full task object in useEffect dependency
  array to avoid unnecessary re-evaluations on every poll.
- Remove unused sendTaskInput mocks from TaskFollowUpShowsResumingProgress
  and TaskFollowUpResumeBuildFailure stories.
- Replace findBy queries inside waitFor blocks with getBy queries since
  waitFor already handles retrying.
@SasSwart SasSwart force-pushed the jjs/internal-1269 branch from 24436e6 to faa3c7e Compare March 6, 2026 12:12
@SasSwart SasSwart enabled auto-merge (squash) March 6, 2026 12:14
@SasSwart SasSwart merged commit 4e781c9 into main Mar 6, 2026
25 checks passed
@SasSwart SasSwart deleted the jjs/internal-1269 branch March 6, 2026 12:20
@github-actions github-actions bot locked and limited conversation to collaborators Mar 6, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tasks: UI auto-resume on send

3 participants