Story (Required)

As a user monitoring my pipelines in GitLab trying to
see the accurate status of my pipeline runs I want
*the GitLab UI to reflect the correct, updated status of my
pipeline runs, so I don't see misleading "starting pipelinerun" messages when
the pipeline has already progressed or completed*

*This story aims to resolve the discrepancy where the GitLab UI shows an
outdated "starting pipelinerun" status, even when the underlying pipeline has
progressed and its status has been successfully updated via an internal status
API. This improves the user experience by providing accurate and timely
pipeline status information, reducing confusion.*

The starting pipelinerun should only be show as fallback if we can't get the
status API updated (due of token not allowed, etc).

Background (Required)

Currently, the GitLab UI continues to display "starting pipelinerun" for a
pipeline, even after an internal status API has successfully updated the
pipeline's actual status. This issue arises despite the latest code being in
place and the status API succeeding. It appears that a fallback mechanism (like
comments) might be overriding or not being correctly updated by the successful
status API, leading to an inaccurate and outdated status being presented to the
user in the GitLab UI. This creates confusion for users who are expecting to
see the real-time status of their pipelines.

Out of scope

• Changing the behavior of the "comments are fallback after status API"
  mechanism itself, unless directly required to fix the status discrepancy.
• Addressing other unrelated GitLab UI status issues.

Approach (Required)

Investigate the integration point between the internal status API and the GitLab status update mechanism. The focus will be on understanding why the GitLab UI isn't reflecting the successful status reported by the API and is instead displaying "starting pipelinerun." This likely involves:

• Debugging the flow from when the status API succeeds to how GitLab's pipeline status is derived.
• Verifying how fallback mechanisms (e.g., pipeline comments) are intended to interact with and be overridden by successful status API calls.
• Identifying the exact point where the outdated status is being perpetuated or where the correct status update is failing to propagate to the GitLab UI.
• Implementing a fix to ensure the successful status API takes precedence and correctly updates the GitLab UI.

  Dependencies

None explicitly identified from the discussion.

Acceptance Criteria (Mandatory)

_ When a pipeline run is initiated, the GitLab UI _initially* displays "starting pipelinerun".
_ When the internal status API successfully updates the pipeline's status to a different state (e.g., 'running', 'completed', 'failed', 'cancelled'), the GitLab UI _must* immediately reflect this updated status.
_ The GitLab UI _must not* continue to show "starting pipelinerun" after the internal status API has reported a different, valid status.

• Verify that the GitLab UI accurately reflects the final status (success, failure, cancellation) of the pipeline run as reported by the status API.

Slack: <https://redhat-internal.slack.com/archives/C0382KN768J/p1760007679062069>