Stop ug configure erroring on feature-disabled workspaces - #500
Merged
Conversation
david-siqi-liu
marked this pull request as ready for review
September 4, 2026 19:52
lilly-luo
reviewed
Sep 4, 2026
lilly-luo
reviewed
Sep 4, 2026
lilly-luo
reviewed
Sep 4, 2026
david-siqi-liu
force-pushed
the
david/ug-configure-wording
branch
2 times, most recently
from
September 6, 2026 15:06
2ef3099 to
87045b6
Compare
david-siqi-liu
changed the title
ug configure erroring on feature-disabled workspaces; hide unramped managed commandsug configure erroring on feature-disabled workspaces
david-siqi-liu
force-pushed
the
david/ug-configure-wording
branch
from
September 6, 2026 20:03
87045b6 to
75f90cb
Compare
lilly-luo
reviewed
Sep 8, 2026
lilly-luo
reviewed
Sep 8, 2026
lilly-luo
approved these changes
Sep 8, 2026
david-siqi-liu
force-pushed
the
david/ug-configure-wording
branch
2 times, most recently
from
September 8, 2026 15:57
b2ab7c0 to
7f4e48d
Compare
`refresh_managed_config` treated FEATURE_DISABLED like a transient read failure and fell back to a stale cached config with the feature-disabled flag unset, masking the disabled state. An admin was then routed into the managed setup flow, which re-read the workspace, got FEATURE_DISABLED, and raised the alarming circular error. Treat FEATURE_DISABLED as authoritative: return no config with the flag set and clear the persisted cache, so `ug configure` stays on the normal per-user flow, a launch does not re-apply a policy the workspace has turned off, and a later transient read or token failure cannot resurrect the disabled policy through the fallback. Also initialize the feature-disabled flag on the `--dry-run` path (a pre-existing UnboundLocalError when the local cache is empty). Co-authored-by: Isaac <no-reply@databricks.com>
david-siqi-liu
force-pushed
the
david/ug-configure-wording
branch
from
September 8, 2026 16:04
7f4e48d to
91df916
Compare
This was referenced Sep 8, 2026
david-siqi-liu
added a commit
that referenced
this pull request
Sep 8, 2026
…AFE flag (#504) ## 🥞 Stack (ug configure + managed-config) - #500 - **#504** ⬅ this PR - #510 --- ## What did you change, and why? Removes the client-side `ENABLE_MANAGED_AGENT_CONFIG` opt-in (a bug-bash flag) and `managed_agent_config_enabled()`. Per team decision, workspace-managed coding-agent config is now gated purely by the server-side SAFE flag, which surfaces as a `FEATURE_DISABLED` reason from `refresh_managed_config` (made authoritative in #500). Two constraints had to keep holding, and do: - Feature disabled server-side means admins and users see nothing about managed config. - omnigent's `ucode configure --profiles DEFAULT --agents claude,codex,pi --use-pat --skip-validate --skip-upgrade` stays fully non-interactive. Where to look: - `cli.py` is the bulk of the diff: deletes the env-var gates, drops the `ug configure` admin auto-routing (it was a passthrough when the flag was unset, so `ug configure` now behaves for everyone as it did for non-flag users), and removes `--skip-managed-config` (it worked by unsetting the now-gone env var). `status` and the launch "no managed config" note now key off the server signal. - Bare `ug` on a feature-disabled workspace prints one managed-free guidance line (run `ug configure`, then `ug <agent>`) instead of a silent no-op. - Launch always fetches and applies the managed config: the cached-launch fast path is gone, so stale local state cannot bypass an admin's config. Correctness over the small per-launch latency. ## How do you know it works? Unit suites (test_cli, test_managed_config, test_managed_wizard, test_lint) green; ruff check and format clean. PR CI green (test + e2e). A prior gpt-6-astra review verified both hard constraints; its one finding (feature-disabled help still surfaced managed-config wording) is addressed by the managed-free guidance line. ## Follow-up (not in this PR) `ug status` reads the managed-config cache directly (`load_managed_state`), with no server-state check, so in a server-side enabled to disabled transition it can surface a stale managed summary until the next `ug configure` or launch clears the cache. Dormant today (the feature is unramped, so the cache is empty everywhere) and self-healing on the next refresh. Deferred: closing it means making `status` refresh from the server, which trades its offline-cheap local-diagnostic nature. Will address before the feature ramps. This pull request and its description were written by Isaac. Co-authored-by: Isaac <no-reply@databricks.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🥞 Stack (ug configure + managed-config)
ug configureerroring on feature-disabled workspaces #500 ⬅ this PRug setupandug publish; ug is developer-only #510What did you change, and why?
Customers running
ug configureon a workspace where server-managed coding-agent config is disabled (FEATURE_DISABLED) hit an alarming, circular error and then dead-ended:Root cause:
refresh_managed_configtreated FEATURE_DISABLED like a transient read failure and fell back to a stale cached config, returning it with the feature-disabled flag unset. That masked the disabled state, so an admin got routed into the managed setup flow, which re-read the workspace, got FEATURE_DISABLED again, and raised the message.The fix is in
managed_config.py: FEATURE_DISABLED is now authoritative. It returns no config with the feature-disabled flag set and clears the persisted cache, soug configurestays on the normal per-user flow, a launch never re-applies a policy the workspace turned off, and a later transient read or token failure cannot resurrect the disabled policy through the fallback. Also initializes the feature-disabled flag on the--dry-runpath (a pre-existing UnboundLocalError on an empty local cache, surfaced by review).Hiding
ug setup/ug publishfrom help and pruning the README, previously bundled here, moved to standalone #510 since it has no dependency on this fix.How do you know it works?
Unit suites (managed_config, cli) green, including new coverage for the feature-disabled cache clear and the dry-run no-crash path. ruff check and format clean. PR CI green (test + e2e).
Live-verified end to end against a real feature-disabled staging workspace (eng-ml-agent-platform, with the
codingAgentConfigCrudEnabledSAFE flag turned off), where the gateway returns:{"error_code":"FEATURE_DISABLED","message":"Coding agent config APIs are not enabled for this workspace."}Invoking
ug configureagainst that workspace as an admin, with a non-empty stale managed config cached (the exact condition that triggered the report):Old build (
0.1.0+81.g95999aa) exits 1 with the circular dead-end error:This branch exits 0 with no error and drops into the normal per-user configure flow. Under the hood
refresh_managed_confignow returns(None, True)and clears the stale cache to{}, so the admin is never routed into the managed-setup dead end.This pull request and its description were written by Isaac.