FYI @m_frankiewicz @dzubova

Summary

This issue is to cleanup the bso_minimal_access_fallback feature flag, after the feature flag has been enabled by default for an appropriate amount of time in production.

The feature controls the behavior of falling back to Minimal Access when provisioning users through SAML, SCIM, or LDAP when Block Seat Overages (BSO) is enabled and no seats are available. The flag was enabled by default in 18.10 (!225777).

Related:

• Feature issue: https://gitlab.com/gitlab-org/gitlab/-/issues/513219
• Rollout issue: https://gitlab.com/gitlab-org/gitlab/-/issues/592790

Owners

• Team: Seat Management
• Most appropriate slack channel to reach out to: #g_seat_management
• Best individual to reach out to: @paulobarros
• PM: @m_frankiewicz

Stakeholders

• Support Team (may receive tickets about unexpected role assignments)

Expectations

What might happen if this goes wrong?

The cleanup MR itself should be low-risk since the flag is already enabled by default. Removing the flag makes the behavior permanent. If an issue is discovered post-cleanup, the fix would require reverting the cleanup MR to re-introduce the flag.

Cleaning up the feature flag

• Specify in the issue description if this feature will be removed completely or will be productized as part of the Feature Flag cleanup
• Verify that external API consumers (e.g., IDE extensions, CLI tools) that may check this feature flag have been updated or can gracefully handle its removal.
• Create a merge request to remove bso_minimal_access_fallback feature flag. Ask for review and merge it.
  • Remove all references to the feature flag from the codebase.
  • Remove the YAML definitions for the feature from the repository.
  • Create a changelog entry.
• Ensure that the cleanup MR has been deployed to both production and canary. If the merge request was deployed before the code cutoff, the feature can be officially announced in a release blog post.
  • /chatops run auto_deploy status <merge-commit-of-cleanup-mr>
• Close the feature issue to indicate the feature will be released in the current milestone.
• If not already done, clean up the feature flag from all environments by running these chatops command in #production channel: /chatops run feature delete bso_minimal_access_fallback --dev --pre --staging --staging-ref --production
• Close the rollout issue.

@dzubova I had a look at the code and given the context shared by Vij and Aish above, I'd estimate this as a weight 3. The main investigation is whether there's been a regression in the members added event, or if seat assignment records are missing for another reason (e.g. members provisioned via SAML/SCIM perhaps? 🤔). WDYT?

@kategrechishkina Good news: the fix was merged yesterday and it seems it will be included in 18.10!

Be aware that the customer will have to enable the ldap_raise_on_search_error feature flag to use the improved logic.

Hey @karichards, could you review this follow-up?

Paulo Barros (cbc6b593) at 17 Mar 20:23

Status update as of 2026-03-16

Summary

1. % Complete: 81%
2. Status: Needs attention

Results

bso_minimal_access_fallback feature flag was enabled by default. BSO warnings for existing and new LDAP/SAML/SCIM configurations are now complete.

Progress

workflowcomplete

• Add BSO warning when enabling BSO with existing... (gitlab#567750 - closed) @karichards
  • MR 1: Add BSO warning when existing user provisioning... (gitlab!224298 - merged)
  • MR 2: Add BSO warning when SAML is configured for Git... (gitlab!224335 - merged)
• Add RA warning when creating LDAP/SAML/SCIM syn... (gitlab#567749 - closed) @karichards
  • MR: Show Restricted Access warning when creating LD... (gitlab!225996 - merged)
• https://gitlab.com/gitlab-org/gitlab/-/issues/592790+ @paulobarros
  • MR: Enable bso_minimal_access_fallback feature flag... (gitlab!225777 - merged)

workflowin review

• Add contract_overages_allowed column to gitlab_... (gitlab#591944) @lwanko
  • MR: Add contract overages allowed attribute to gitl... (gitlab!226299)
• Update Subscription API to accept contract_over... (gitlab#591945) @lwanko
  • MR: Add contract_overages_allowed to gitlab_subscri... (gitlab!226507)

workflowready for development

• Show Restricted Access status and inform about ... (gitlab#580284) @lwanko

workflowrefinement

• Send notification when protocol-provisioned use... (gitlab#580421) @lwanko

FYI @m_frankiewicz @dzubova @lwanko @karichards

Follow-up to !226913.

What does this MR do and why?

1. Fixes a logging gap where non-error LDAP response codes (10, 32) were silently returned without logging. All non-zero codes now log a warning before the allowlist check.

2. Removes codes 3 (TIMELIMIT_EXCEEDED) and 4 (SIZELIMIT_EXCEEDED) from NON_ERROR_LDAP_RESPONSE_CODES. These codes are already handled by net-ldap as successful searches and never reach check_empty_response_code.

References

• !226913
• #6054

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.

Paulo Barros (8373165a) at 16 Mar 19:27

@kategrechishkina Right, codes 3/4 are in net-ldap's ResultCodesSearchSuccess so they return results directly, not nil. If an admin wants to retry on those they can use retry_empty_result_with_codes. On the logging gap, agreed, I'll track that in the follow-up issue.

However, despite all the efforts I'm afraid it's unlikely that this fix will be merged on time for 18.10.

cc @m_frankiewicz @dzubova

Apologies @dzubova, I was supposed to have a look at this but got sidetracked. I will do it later today. Thanks for the patience.

@lwanko @sgarg_gitlab Good call on the naming, renamed the FF to ldap_raise_on_search_error. On codes 3/4, net-ldap treats those as successful searches and returns results directly, so they wouldn't normally hit check_empty_response_code. Code 32 was a deliberate choice since it covers legitimate cases like a deleted LDAP group. These could use a closer look though, I'll create a follow-up issue for it.