Repository navigation
chore(coderd/provisionerdserver): avoid fk error on invalid ai_task_sidebar_app_id - #19253
Conversation
| Level: []database.LogLevel{database.LogLevelWarn}, | ||
| Stage: []string{"Cleaning Up"}, | ||
| Output: []string{ | ||
| fmt.Sprintf("Unknown ai_task_sidebar_app_id %q. This workspace will be unable to run AI tasks. This may be due to a template configuration issue, please check with the template author.", sidebarAppID.UUID.String()), |
There was a problem hiding this comment.
Linking to some docs could be beneficial if this is the template author viewing the message. I.e. how will the author know how to resolve this/why it happened?
There was a problem hiding this comment.
That's a good point. Which documentation should we link to?
There was a problem hiding this comment.
Ah, it looks like we don't really have any related docs yet. Perhaps we could give a hint as to what the most common cause of the error is, as well as link to https://registry.terraform.io/providers/coder/coder/latest/docs/resources/ai_task?
| task := jobType.WorkspaceBuild.AiTasks[0] | ||
| if task.SidebarApp == nil { | ||
| return xerrors.Errorf("update ai task: sidebar app is nil") | ||
| if task.SidebarApp == nil || len(task.SidebarApp.Id) == 0 { |
There was a problem hiding this comment.
Suggestion: Use getters for safer access (fixing all non-getter uses is out of scope though)
This is a workaround for #18776
We avoid the foreign key issue by checking the previously inserted workspace applications before calling UpdateWorkspaceAITask. Now, affected workspaces will show as "not running an AI task" on the single task view, which is technically correct.
We also insert a provisioner job log at WARN level to ensure that the user sees some information that they have run into this issue, as well as logging on the server side.
Longer term, we plan to modify how the workspace tasks view is presented. This is a stopgap measure until we solidify that plan.
NOTE: this does not address the fact that stopping a workspace with
has_ai_task: truewill result in the completed stop build no longer havinghas_ai_task: true, resulting in tasks "disappearing" on stop.