MR: Pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description Insights as a result of this work: https://gitlab.com/groups/gitlab-org/-/epics/14664+ When we attempt to pull an image on the agent side for a workspace but fail to do so, we get an `ImagePullBackOff` that is not reported as a failed state to the rails side. This leads to the workspace being stuck on the creating state on the UI, even though we could not pull the image. I think this error is not reported by the applier that applies the manifests, but rather as a field present in the pod status. It could maybe be an intermittent failure that k8s resolves on retry, if so we may need to determine after how long a "pull" operation can last before we report it as fail (or piggyback on something Kubernetes already exposes for this) ## Acceptance Criteria - [ ] Report image pull errors that have reached the retry limit to the rails side and by extension the UI. ## Technical Requirements ## Design Requirements ## Impact Assessment ## User Story <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://handbook.gitlab.com/handbook/engineering/development/dev/create/remote-development/#-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->