Improve job final update mechanism

Romuald Atchadé - OOO until Jan 11th, 2026requested to merge
allow-configurability-of-trace-final-update into main

What does this MR do?

Improve final update mechanism by:

  • Making the final update count configurable
  • Adding a backoff to the final update retries

Why was this MR needed?

As explained, in the issue linked, since !4692 (merged) GitLab Runner discards the final update for a job (leaving it stuck in the pipeline as “running”) if the GitLab server is restarting (and therefore unavailable) when the job finishes.

The implementation made in the MR didn't allow configurability of the finalUpdateCount and would end up with the issue observed if the attempts to send this final update expired before the GitLab instance is once again available.

What's the best way to test this MR?

TBD

What are the relevant issue numbers?

close #38017 (closed)

Merge request reports