Unknown Default Org Fallback code paths

Current.organization is derived from Gitlab::Current::Organization. We use Gitlab::Organizations::FallbackOrganizationTracker to understand in what cases we fallback to the default organization.

The tracking is controlled by track_organization_fallback feature flag. As of writing (2026-05-07), this feature flag is disabled. This is because of this issue. The root cause has been fixed in !234762 (merged) so we can turn on this feature flag when we work on this issue. We can start with a small percentage.

If a fallback is found, we send an event fallback_current_organization_to_default which can be viewed in [Tableau Internal]. (https://10az.online.tableau.com/#/site/gitlab/views/SnowplowEventExplorationLast30Days/SnowplowEventExplorationLast30D/480ab467-c8cb-4b37-91cc-e8a2e351860a/CurrentOrganizationFallbackTracking?:iid=1):

The Event Label is populated using caller_id which is set in different places.

After asking in internal #g_observability Slack channel, @reprazent provided more context about this caller_id:

When there are code-paths where it isn't set, we try to add them. The known attempts are in ApplicationController (https://gitlab.com/gitlab-org/gitlab/-/blob/1f819ab341d69564f5e37b7bbd788dc2408043e8/app/controllers/application_controller.rb#L451), a middleware here https://gitlab.com/gitlab-org/gitlab/-/blob/1f819ab341d69564f5e37b7bbd788dc2408043e8/lib/gitlab/middleware/action_controller_static_context.rb#L21, or Grape here: https://gitlab.com/gitlab-org/gitlab/-/blob/1f819ab341d69564f5e37b7bbd788dc2408043e8/lib/api/api.rb#L89. For Sidekiq this happens in a middleware.

Possible root cause

It requires the controller to be an ApplicationController , or otherwise include that module: https://gitlab.com/gitlab-org/gitlab/-/blob/1f819ab341d69564f5e37b7bbd788dc2408043e8/app/controllers/application_controller.rb#L26 I think we saw cases where the controller is not inheriting from ApplicationController , but instead using something like from a Gem. That might be the case here

Possible solution

Add caller_id logic to Doorkeeper controllers and see if that helps.

So we might have a few controllers that do not have this caller_id set. the controllers that Doorkeeper are potential candidates.

I know devise does some tricks to also be an ApplicationController, but maybe for those doorkeeper things we can just add the EndpointAttributes so we at least have the caller_id set.