Impossible to edit Tasks prompt while waiting for the workspace to spin up

[bartekgatzcoder]

Imagine a scenario where the user makes a silly error in the original prompt, but clicks the "start task" ⬆ button. If that mistake was made the user will have to wait up to several minutes for the workspace to be created with no way of editing the prompt.

In addition, the original prompt is not visible on screen while the workspace is being spun up:

I think it would be super useful to show the prompt window there and say something like "you may still fine tune your prompt while the workspace is being started". This could save me a ton of waiting time.

[johnstcn]

I think it would be super useful to show the prompt window there and say something like "you may still fine tune your prompt while the workspace is being started". This could save me a ton of waiting time.

This is going to be tricky. At this point, the prompt is essentially set in stone. We would have to modify where the prompt comes from -- instead of from the provisioner, it would have to come from the Coder API (maybe from a new CLI command coder exp task prompt "${TASK_ID}"?)

[mtojek]

If you look at how ChatGPT works, there is "Stop" button which lets you send another prompt. Would that be an option? I mean, start another tasks and kill the old one in the background.

[DanielleMaywood]

I'm unable to give a complexity to this issue as the complexity depends on the solution we're looking at here. Giving some nice UI way of stopping, changing the prompt, and restarting, would probably be a 1 but changing in-flight would be way larger.

[johnstcn]

If you look at how ChatGPT works, there is "Stop" button which lets you send another prompt. Would that be an option? I mean, start another tasks and kill the old one in the background.

This would be much simpler. 👍

[bartekgatzcoder]

Are the operations issued through a "send" command somehow queued on our side? Could we check the queue for any changes in the precise moment when the Agentinc module is kicked off?

[DanielleMaywood]

@bartekgatzcoder The prompt is made available to the workspace in terraform. By the time you've started a workspace build it is too late to change it.

[bartekgatzcoder]

But that is exactly my point. Could Agentic AI pick the prompt from the queue, instead of the terraform? If the initial prompt was also queued (Assuming there is a queue behind the "send" action), this could add the desired flexibility of editing the prompt / overwriting it while the workspace starts.

[johnstcn]

Could Agentic AI pick the prompt from the queue, instead of the terraform?

It would need fundamental changes to how this is all wired together and would likely need an RFC, or at least a proof-of-concept.

[mtojek]

Assuming there is a queue behind the "send" action

@bartekgatzcoder That queue behind send are provisioner_jobs, and under proper setup, that queuing should last a couple of seconds, unless provisioners are busy. I'm not convinced if this is worth it.

#1084 (comment)

Actually, this is still my favourite option.

[DanielleMaywood]

The following information is not strictly relevant to this issue, but useful context:

During the bug bash yesterday, we discovered a limitation (at least on Linux) with how we
currently pass prompts through to the agent.

On linux, environment variables are length-limited to (PAGE_SIZE * 32) ¹. Typically the page size is 4KiB, meaning an environment variable is limited to 128KiB of data in a typical setup.

We might investigate an alternative method of providing the task to a task workspace given this limitation, and this issue could benefit from that.

Footnotes

1. https://github.com/torvalds/linux/blob/e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6/include/uapi/linux/binfmts.h#L15 ↩