[prebuild] Not starting workspace once the prebuild is done

[geropl]

Instead, user is left handing with prebuild log, reading "exit" at the end. Reload starts the workspace properly.

Screenshot:

Idea: Might be triggered by us fixing the status updates recently.

/cc @jldec not the issue I had in mind during our meeting, but annoying nonetheless

[jldec]

@geropl can you clarify how to to repro this?

What do you have to do, to see a prebuild log (I assume in the dashboard) when you are expecting to start a workspace?

[geropl]

can you clarify how to to repro this?

@jldec This happened to me a couple of times last days (1 week) now on the gitpod-io/gitpod repo. I started a workspace, and was show the "Prebuild in progress" view with logs flowing in. I left the tab as this usually takes a couples of minutes.
When I came back the prebuild had clearly finished (noticable because of the last line saying "exit"). Now, because we don't show the actual status of that prebuild, I'm not sure if a) the prebuild was completed, or b) just the execution was finished, but it was still uploading the result.
But when I hit "F5", the workspace started immediately based on this (another?) prebuild.

[jankeromnes]

Could it be that we don't properly handle websocket reconnections? (They are quite likely on long-running pages that you might leave open in the background.)

This is just a random guess, but I believe we might need something like a notifyDidOpenConnection listener to handle reconnections.

For example, this is how the ImageBuildView seems to handle websocket reconnections when you're starting a workspace and watching image build logs (i.e. it calls watchBuild again):

gitpod/components/dashboard/src/start/StartWorkspace.tsx

Lines 684 to 698 in bfa4c16

	const toDispose = getGitpodService().registerClient({
	notifyDidOpenConnection: () => {
	registered = false; // new connection, we're not registered anymore
	watchBuild();
	},
	onWorkspaceImageBuildLogs: (
	info: WorkspaceImageBuild.StateInfo,
	content?: WorkspaceImageBuild.LogContent,
	) => {
	if (!content) {
	return;
	}
	logsEmitter.emit("logs", content.text);
	},
	});

The StartWorkspace.tsx page used to do something similar (calling watchHeadlessWorkspace again on reconnections):

    const toDispose = service.registerClient({
      notifyDidOpenConnection: () => watchHeadlessWorkspace(),
      onHeadlessWorkspaceLogs(event: HeadlessLogEvent): void {
        logsEmitter.emit('logs', event.text);
      },
    });

but the notifyDidOpenConnection call got removed in the refactor to watchHeadlessLogs: 71cc5eb#diff-1782bf62bd01382ce9f0a5f65a2d8ad7f2cc1b7c87f8d119dd3c818f91019266L349

I'm not entirely sure, but is it possible that the "new" watchHeadlessLogs might break on websocket reconnections?

[geropl]

Could it be that we don't properly handle websocket reconnections?

Exactly my suspicion, yes. Will try to fix. 🙃

Update: After looking through the code and checking blame I think it's sth else. The expectation was that the outer code (e.g., StartWorkspace) switches screens, but that seems to have gone missing. Now looking into re-using PrebuildLogs.

[AlexTugarev]

I was just hitting the same issue. I forgot to take a screenshot, but I verified that the onPrebuildUpdated (available) event was received on 2nd or 3rd websocket connection and not on the initially created one.

[geropl]

This did not see much work due to installer, and I'm on sick leave, so moving back to "scheduled".

[josepjaume]

Hi! Sorry to chime in - this is a major blocker for us at Factorial, and probably the first source of frustration to transition to Gitpod. It gives people a sense of "unstability". In big repos with lots of activity, having to start over again makes people nervous 🙃. People end up understanding that they need to refresh at the end of the process, but that's far from ideal (especially given that from that moment on, everything works flawlessly).

That said, I love the product and I think you're doing an amazing job. Take care @geropl, and sorry to bother you while on sick leave!

[geropl]

@AlexTugarev Was just able to reprodue this on staging. 👍

[AlexTugarev]

@geropl, I think I could reproduce it myself.

[AlexTugarev]

Reopening this after realizing that the PR only solves it for one user – the webhook installer. For other users, no instance updates will be sent, thus the process breaks.