-
Notifications
You must be signed in to change notification settings - Fork 881
Final output on workspace creation shows "connecting" forever - confusing UX #1036
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@tjcran We have already done grooming for this sprint (last sprint of Beta) is this an intentional injection or can this move to Community MVP? |
@kylecarbs I added you to poker planning for this but there may be others you want to add. I am just assuming that this fix will be you. |
I'm not able to repro on version Coder v0.5.2-devel+568574c with docker-local template. @f0ssel if you're still able to repro, can you give some more details, i.e. the template you are using?
|
Because this is a "confusing UX" item and also not consistently reproduced, I am removing this as a |
@mafredri can you add details here for what you see when the command completes but the connecting state does not ever change? |
Here's how I've reproduced the original issue (latest Start the server:
On the CLI side:
Here the Logs`./coder templates create -d examples/docker-local`
`./coder server --dev --address 0.0.0.0:7080 --access-url http://0.0.0.0:3000`
@spikecurtis Does this help? |
Actually, since I can reproduce this quite reliably, I can grab this if nobody's working on it (I'll self assign, let me know if someone is already on it). |
This might be a red herring, but why are you setting I'm wondering if setting the access URL to port 3000 is causing the workspace coder agent to fail connecting, and this contributes to you being able to repro but I cannot. I think we need to decide on the desired UX here. Should the CLI wait until coder agents have connected? If so, how long before giving up and throwing an error? If not, then how to do we communicate to the end user? The reality is that their agent(s) haven't connected yet, but it's probably fine, unless it isn't and then they need to debug. |
Good catch, I think that's bad copy-pasta from some Docker experiments, and it was indeed a red herring since it was being overridden by the Docker template. I just re-tested, and the behavior is the same. I tried creating 3 workspaces, the two first were left at
I think for a quick improvement we could increase the wait ever so slightly since, as I observed above, it's a tad bit racy at the moment. And after that we just inform the user that we're no longer waiting but their workspace is finishing up. I think that's the best we can do in the Then again, I don't know how much heavy lifting terraform apply is doing here. Is it waiting until everything has been created successfully, or just scheduling (e.g. with k8s) for creation? If it's the former, it shouldn't take long for the agent to dial home, if it's the latter it could take an hour. |
It depends on the terraform template, so we don't have any way to know a priori. |
Looks like right now it's not waiting at all; it just queries the resources after the job completes. So it's a race between the agent starting and connecting and the query returning. @tjcran given that we show the resources we're about to create before the confirm, do we really want to show them again after the job is done? We're not giving the users any new information except for the connection status of agents, and this is the very thing that is racy and confusing. I think we should just drop it at the end of the |
I think a small incremental improvement on the UX here would be sufficient, we could track re-thinking the create flow in a new issue. Regarding the preview and post-resource views, they do give out slightly different information. So not sure we wan't to replace one with the other? (Here I noticed there's a discrepancy between the access output and workspace arch missing in preview, not sure if it's intentional that one says persistent and the other ephemeral though.) Anyway, I'll unassign this from me and set the needs decision tag as I think @spikecurtis has some valid points and I lack the context to make a decision about it. |
I'm in favor of dropping it, @kylecarbs made the original flow so he may have thoughts, but since he's on PTO I don't think we need to wait for his input since he can give input / reimplement correctly later. |
@f0ssel So we'd be dropping / not showing the resource view after creation? What about the preview, there's a mis-match of information between the two -- which is the source of truth and do we know the persistent/ephemeral status before creation is complete, and do we need to show it? Do you have any thoughts on this @kylecarbs? |
I think what's happening with the resources state being inconsistent is a bug, but it's a different bug than what's being tracked in this issue, so I'll raise a new issue to track: #1937 Let's concentrate on this issue with the "connecting" UX, and I think the best plan is still to just drop the second round of showing the resources on |
This change avoids a confusing UX where the workspace agent shows "connecting" after create has completed. Fixes #1036
We should probably make it clear that we aren't waiting here, since it seems like the CLI is going to wait for the "connecting" to change to "connected".
The text was updated successfully, but these errors were encountered: