Connect tries to login to previous session instead of logging in to the DeviceWebToken's session about teleport

[ravicious]

Launching a deep link waits until the frontend app is ready:

teleport/web/packages/teleterm/src/mainProcess/windowsManager.ts

Lines 180 to 184 in 606bcb1

	async launchDeepLink(
	deepLinkParseResult: DeepLinkParseResult
	): Promise<void> {
	try {
	await this.whenFrontendAppIsReady();

Currently the readiness is signaled after WorkspacesService.prototype.restorePersistedState resolves, which includes a call to restore the previous workspace. This is what triggers the login modal for the previous cluster and waits until that modal is closed.

teleport/web/packages/teleterm/src/ui/AppInitializer/AppInitializer.tsx

Lines 40 to 43 in 606bcb1

	await showStartupModalsAndNotifications(appContext);
	appContext.mainProcessClient.signalUserInterfaceReadiness({
	success: true,
	});

teleport/web/packages/teleterm/src/ui/AppInitializer/showStartupModalsAndNotifications.ts

Lines 28 to 51 in 606bcb1

	/**
	* Runs after the UI becomes visible.
	*/
	export async function showStartupModalsAndNotifications(
	ctx: IAppContext
	): Promise<void> {
	const { configService } = ctx.mainProcessClient;
	await askAboutUserJobRoleIfNeeded(
	ctx.statePersistenceService,
	configService,
	ctx.modalsService,
	ctx.usageService
	);
	// Setting up usage reporting after asking for a job role prevents a situation
	// where these dialogs are shown one after another.
	// Instead, on the first launch only "usage reporting" dialog shows up.
	// "User job role" dialog is shown on the second launch (only if user agreed to reporting earlier).
	await setUpUsageReporting(configService, ctx.modalsService);
	// If there's a workspace that was active before the user closed the app, restorePersistedState
	// will block until the user interacts with the login modal (if the cert is not valid anymore) and
	// the modal for restoring documents.
	await ctx.workspacesService.restorePersistedState();

The solution would be to:

1. Move this.setActiveWorkspace out of WorkspacesService.prototype.restorePersistedState into showStartupModalsAndNotifications. (restorePersistedState is called only once in the app).
2. Signal readiness after restorePersistedState but before setActiveWorkspace.
   • Similarly, isInitialized of WorkspacesService should be set to true after restorePersistedState but before setActiveWorkspace. This affects VNet only though, not deep links.
3. Make setActiveWorkspace accept a signal.
4. WindowsManagerIpc.SignalUserInterfaceReadiness should return an AbortController that aborts the signal passed to setActiveWorkspace in showStartupModalsAndNotifications.
5. WindowsManager.prototype.launchDeepLink should pass the abort controller to DeepLinksService.prototype.launchDeepLink in the render process.
   • So far, each deep link handler already sets the correct workspace by calling loginAndSetActiveWorkspace. That method should abort the abort controller and show the modal for the right workspace. We cannot always abort the controller, because in the future there might be deep links that are not related to a particular workspace.

Instead of passing an abort controller back and forth between processes through WindowsManagerIpc.SignalUserInterfaceReadiness, perhaps we can create a single abort controller in AppContext (called, idk, restoreWorkspaceAbortController) and then pass it to both DeepLinksService and showStartupModalsAndNotifications.

[codingllama]

As @avatus put it, in much fewer words:

1. Connect opens and tries to open any sessions
2. Sees the expired session and tries to reauth
3. Now that its done "starting", it opens the deep link

[codingllama]

It's probably the same, but we should also consider what happens with distinct users for the same cluster.