Fix: Clear BatchLoader state on Action Cable subscription updates

<🤖>

What does this MR do and why?

Adds ::BatchLoader::Executor.clear_current at the start of Gitlab::Graphql::Subscriptions::ActionCableWithLoadBalancing#execute_update, behind the new note_session_bar_action_cable_reload WIP feature flag (disabled by default).

Action Cable subscription updates run on long-lived threads that never pass through the Rack or Sidekiq BatchLoader middleware. Without this clear, a value batched for one update is reused by every later update on the same thread, which can serve stale data to the note session bar (and any other GraphQL subscription).

Because execute_update is the transport for every GraphQL subscription update (issues, merge requests, pipelines, CI, work items), this change is gated behind a feature flag so it can be rolled out — and rolled back — independently.

Split out of !250297 (merged) as requested in !250297 (comment 3823457502).

References

Screenshots or screen recordings

Backend-only change behind a disabled-by-default feature flag; no UI changes.

How to set up and validate locally

  1. In a Rails console, enable the feature flag:
    Feature.enable(:note_session_bar_action_cable_reload)
  2. Trigger a GraphQL subscription update that batches values (for example, a note update that broadcasts to subscribers) and observe that values batched before the update are not reused after it.
  3. Run bundle exec rspec spec/lib/gitlab/graphql/subscriptions/action_cable_with_load_balancing_spec.rb to verify both the enabled and disabled flag states.

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

Loading
Loading