feat(site): allow modifying task prompts for starting tasks #20812
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
This PR adds the backend implementation for modifying task prompts. Part of coder/internal#1084 ## Changes - New `UpdateTaskPrompt` database query to update task prompts - New PATCH `/api/v2/tasks/{task}/prompt` endpoint ## Notes This is part 1 of a 2-part PR stack. The frontend UI will be added in a follow-up PR based on this branch (#20812). --- 🤖 PR was written by Claude Sonnet 4.5 Thinking using [Coder Mux](https://github.com/coder/cmux) and reviewed by a human 👩
This PR adds the backend implementation for modifying task prompts. Part of coder/internal#1084 ## Changes - New `UpdateTaskPrompt` database query to update task prompts - New PATCH `/api/v2/tasks/{task}/prompt` endpoint ## Notes This is part 1 of a 2-part PR stack. The frontend UI will be added in a follow-up PR based on this branch (#20812). --- 🤖 PR was written by Claude Sonnet 4.5 Thinking using [Coder Mux](https://github.com/coder/cmux) and reviewed by a human 👩
aaaa792 to
fbc125b
Compare
fbc125b to
2fece8e
Compare
mafredri
left a comment
There was a problem hiding this comment.
The flow seems correct to me.
Visually I think it'd be beneficial to not just show "you can edit the prompt while ...", but also show the actual prompt here. Re-reading the prompt while waiting may help spark an idea for the user to more likely use the feature.
I also ran into the dialogue open but disabled "cannot change for active task". But that's because my sample template is very fast. It felt a bit clunky but I have no suggestion for improvement.
I'll defer FE patterns review to Kayla.
I am very open to any suggestions to improve this. I can fully understand the clunky feeling of it |
| } | ||
|
|
||
| const stopBuild = await API.stopWorkspace(workspace.id); | ||
| await API.waitForBuild(stopBuild); |
There was a problem hiding this comment.
Shouldn't we also handle this with a try-catch, in case the stop workspace build fails?
| workspace.latest_build.build_number, | ||
| ); | ||
|
|
||
| if (currentBuild.status !== "stopped") { |
There was a problem hiding this comment.
This means that we are allowing this operation in all other build status, like running, right? In that case, this will cancel a workspace that is already running, is that expected? Shouldn't we just support currentBuild.status === pending || currentBuild.status === starting?
- Move to using `formik` and a form - Remove unneeded comment - Use DialogClose component - Use `useId` instead of hard-coded IDs
| ): Promise<void> => { | ||
| await this.axios.patch(`/api/v2/tasks/${user}/${id}/input`, { | ||
| input, | ||
| } satisfies TypesGen.UpdateTaskInputRequest); |
There was a problem hiding this comment.
god I love the satisfies keyword. thank you for actually knowing how to use it correctly. 💕
This PR adds the frontend implementation for modifying task prompts. Closes coder/internal#1084
🤖 PR was initially written by Claude Sonnet 4.5 Thinking using Coder Mux and then heavily modified by a human 👩