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
- Split from: !250297 (merged)
- Reviewer request: !250297 (comment 3823457502)
- Related work item: #624326 (closed)
Screenshots or screen recordings
Backend-only change behind a disabled-by-default feature flag; no UI changes.
How to set up and validate locally
- In a Rails console, enable the feature flag:
Feature.enable(:note_session_bar_action_cable_reload) - 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.
- Run
bundle exec rspec spec/lib/gitlab/graphql/subscriptions/action_cable_with_load_balancing_spec.rbto 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.
</