Log warning instead of tracing error span

[jenting]

Description

Log warning instead of tracing error span if the error message contains cannot find workspace.

Related Issue(s)

Fixes #11710
Fixes #11713

How to test

None

Release Notes

None

Documentation

None

Werft options:

• /werft with-preview

[jenting]

I'm thinking about whether we should handle this kind of error within ws-manager, rather than ws-daemon.

We made a similar approach for WaitForInit function, special handling the gRPC not found error.

gitpod/components/ws-manager/pkg/manager/monitor.go

Lines 684 to 698 in e40e43d

	if st, ok := grpc_status.FromError(err); ok && st.Code() == codes.NotFound {
	// Looks like we have missed the CREATING phase in which we'd otherwise start the workspace content initialization.
	// Let's see if we're initializing already. If so, there's something very wrong because ws-daemon does not know about
	// this workspace yet. In that case we'll run another desperate attempt to initialize the workspace.
	m.initializerMapLock.Lock()
	if _, alreadyInitializing := m.initializerMap[pod.Name]; alreadyInitializing {
	// we're already initializing but wsdaemon does not know about this workspace. That's very bad.
	log.WithFields(wsk8s.GetOWIFromObject(&pod.ObjectMeta)).Error("we were already initializing but wsdaemon does not know about this workspace (bug in ws-daemon?). Trying again!")
	delete(m.initializerMap, pod.Name)
	}
	m.initializerMapLock.Unlock()
	// It's ok - maybe we were restarting in that time. Instead of waiting for things to finish, we'll just start the
	// initialization now.
	err = m.initializeWorkspaceContent(ctx, pod)

WDYT? @csweichel @aledbf @kylos101

[csweichel]

I'm thinking about whether we should handle this kind of error within ws-manager, rather than ws-daemon.

We made a similar approach for WaitForInit function, special handling the gRPC not found error.

gitpod/components/ws-manager/pkg/manager/monitor.go

Lines 684 to 698 in e40e43d

	if st, ok := grpc_status.FromError(err); ok && st.Code() == codes.NotFound {
	// Looks like we have missed the CREATING phase in which we'd otherwise start the workspace content initialization.
	// Let's see if we're initializing already. If so, there's something very wrong because ws-daemon does not know about
	// this workspace yet. In that case we'll run another desperate attempt to initialize the workspace.
	m.initializerMapLock.Lock()
	if _, alreadyInitializing := m.initializerMap[pod.Name]; alreadyInitializing {
	// we're already initializing but wsdaemon does not know about this workspace. That's very bad.
	log.WithFields(wsk8s.GetOWIFromObject(&pod.ObjectMeta)).Error("we were already initializing but wsdaemon does not know about this workspace (bug in ws-daemon?). Trying again!")
	delete(m.initializerMap, pod.Name)
	}
	m.initializerMapLock.Unlock()
	// It's ok - maybe we were restarting in that time. Instead of waiting for things to finish, we'll just start the
	// initialization now.
	err = m.initializeWorkspaceContent(ctx, pod)

WDYT? @csweichel @aledbf @kylos101

Agreed - handling this in ws-manager is the better way. For one, from ws-daemon's perspective the lifecycle of the workspace has actually ended, and keeping info about that workspace beyond this point doesn't feel "natural". From ws-manaer's perspective it's easier to keep the Git status in memory because the workspace still exists.