Skip to content

Default Real-time Assignees feature flags to on

Summary

Now that a real-time feature has been supported in production on GitLab.com for over a quarter we can default the feature flag to on.

This feature depends on two feature flags:

  • real_time_issue_sidebar determines whether the frontend should attempt to establish a WebSocket connection
  • broadcast_issue_updates determines whether the backend should broadcast updates to issues over the WebSocket connection

In both cases real-time behaviour is contingent upon the feature flag being enabled OR Action Cable configuration being detected.

This allows an installation to support WebSocket requests on nodes other than those serving the frontend client, as the feature flag can force the feature to on.

Instead we should change the relationship to AND and default the feature flag to on, effectively switching on real-time wherever Action Cable is configured but retaining the ability to switch it off as a contingency.

Impact for GitLab.com

All nodes will need to have Action Cable configured, including those that don't actually serve Action Cable requests.

  • Could interfere with some metrics that are reported specifically from nodes with Action Cable switched on.
  • Could create some increase in memory, though it has been determined that just mounting Action Cable has a minimal effect on memory use (see #supporting-evidence).

Impact for self-hosting customers

  • Those without Action Cable configured will see no change (in behavior).
  • Those that have configured Action Cable but switched the FF off will see no change.
  • Those with Action Cable already configured will continue to see real-time features.
  • Those that use the feature flag to enable real-time features without configuring Action Cable on the same nodes will no longer see real-time features until they enable Action Cable on those nodes.

Supporting evidence

We've done everything we can to establish that just mounting the Action Cable engine has little to no effect on memory or CPU.

See gitlab-org/quality/performance#256 (comment 443099618), which details resource usage on the 10k architecture and was inconclusive as the difference was within the margin of error.

Proposal

  • Configure Action Cable for all GitLab.com web nodes
  • Default broadcast_issue_updates to on and AND it with Gitlab::ActionCable::Config.in_app? (or just remove this one?)
  • Default real_time_issue_sidebar to on and AND it with Gitlab::ActionCable::Config.in_app?

Alternatives considered

  • Turn real_time_issue_sidebar into a generic configuration setting that allows the toggling of WebSockets on the frontend.
  • Assume WebSockets are available on the frontend and gracefully degrade (currently uses exponential backoff).
Edited by John Hope