Fix the pipeline header refresh, remove wait_for_requests

Asherah Connorrequested to merge
kiv/fix-the-pipeline-header-refresh-remove-wait-for-requests into master

What does this MR do and why?

refreshPipelineGraph marks the query as un-skipped via canRefetchHeaderPipeline, and then calls refetch, but vue-apollo only starts the query after the next reactivity tick; headerPipeline's skip() only gets read then; the refetch call is a no-op.

After the next reactivity tick, the skip() takes effect, and the query is run, it hits the cache and it just serves the still-stale data from cache; refetch ran too early to affect it.

Adding a $nextTick wait makes this actually do something; after it resolves, the skip() update has taken effect, and then the refetch actually does what it's meant to.

This used to poll, back before 26f40d1a, and so we had a bit of a safety net. Since then we've only relied on the subscription. The CI flake looks like this:

  • Page loads. Header query resolves, writes its initial 'pending' state into cache. subscribeToMore is called and starts to establish the subscription.
  • Capybara clicks the graph action as soon as the button can be found; this can be very early!
  • The POST processes synchronously on the server (Sidekiq running inline): the build transitions, pipeline changes to 'running', and the trigger broadcasts during the request.
  • If the broadcast occurs before the subscription is fully established (it takes some time), the event gets lost.

refreshPipelineGraph was meant to cover for this, but it was actually doing nothing!

Sample failures from this:

This discovery fell out of the wait_for_requests removal work of Remove all uses of `wait_for_requests`, `wait_f... (&22879). This MR also reworks the wait_for_requests in the associated specs to wait on page elements that reliably tell us when we can proceed in the spec.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports