Skip to content

Stop ug configure erroring on feature-disabled workspaces; hide unramped managed commands - #500

Open
david-siqi-liu wants to merge 4 commits into
mainfrom
david/ug-configure-wording
Open

Stop ug configure erroring on feature-disabled workspaces; hide unramped managed commands#500
david-siqi-liu wants to merge 4 commits into
mainfrom
david/ug-configure-wording

Conversation

@david-siqi-liu

Copy link
Copy Markdown
Collaborator

Problem

Customers running ug configure on a workspace where workspace-managed coding-agent configs are disabled server-side (FEATURE_DISABLED) hit an alarming, circular error and then dead-ended:

ERROR Workspace-managed coding agent configuration is not available on this workspace. Use `ug configure` to set up agents for individual users instead.

Root cause: refresh_managed_config treated 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 was routed into the managed setup flow, which re-read the workspace, got FEATURE_DISABLED, and raised the message.

Changes

  • managed_config.py: treat FEATURE_DISABLED as authoritative rather than transient. Return no config with the feature-disabled 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.
  • cli.py: initialize the feature-disabled flag on the --dry-run path. This was a pre-existing UnboundLocalError when the local cache was empty, surfaced by review.
  • Docs and help: remove the managed-config authoring surface (ug setup and ug publish) from the public README, and hide those commands from ug --help, while workspace-managed configs are still in development and unramped. They remain runnable behind ENABLE_MANAGED_AGENT_CONFIG. ug export stays documented.

Testing

  • The affected pytest suites (managed_config, cli, managed_wizard) all pass, including new coverage for the feature-disabled cache clear, the dry-run no-crash path, and the hidden-but-runnable setup/publish commands.
  • ruff clean.

Review

Ran a simplify pass (no changes needed) and a Codex adversarial review. The two P1 findings it surfaced, persisted-cache resurrection and the pre-existing dry-run crash, are both fixed here.

This pull request and its description were written by Isaac.

…amped managed commands

Customers running `ug configure` on a workspace where workspace-managed
coding-agent configs are disabled server-side hit an alarming, circular
"ERROR ... Use `ug configure`" message and dead-ended. Root cause:
refresh_managed_config treated FEATURE_DISABLED like a transient read failure
and fell back to a stale cached config, masking the disabled state and routing
an admin into the managed setup flow, which then raised the message.

- managed_config.py: treat FEATURE_DISABLED as authoritative. Return
  (None, feature_disabled=True) and clear the persisted cache, so `ug configure`
  stays on the per-user flow, a launch does not re-apply a policy the workspace
  turned off, and a later transient failure cannot resurrect it.
- cli.py: initialize coding_agent_config_feature_disabled on the --dry-run path
  (pre-existing UnboundLocalError when the local cache was empty).
- Remove the managed-config authoring surface (ug setup / ug publish) from the
  public README and hide those commands from `ug --help` while the feature is
  still in development and unramped. They stay runnable behind
  ENABLE_MANAGED_AGENT_CONFIG; `ug export` stays documented.

Co-authored-by: Isaac <no-reply@databricks.com>
@david-siqi-liu
david-siqi-liu marked this pull request as ready for review September 4, 2026 19:52
Comment thread src/ucode/managed_config.py Outdated
Comment thread src/ucode/cli.py Outdated
Comment thread src/ucode/cli.py Outdated
Comment on lines +2426 to +2430
# --dry-run avoids the fetch but still applies the last saved config. It doesn't reach the
# gateway, so the feature-disabled signal is unknown here — default it to False so the guidance
# check below is well-defined (without this, a dry run with no cached config raised
# UnboundLocalError).
coding_agent_config_feature_disabled = False

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you just return here and comment out everything below? or at least make this a hidden env var that we can use to test/

david-siqi-liu and others added 3 commits September 4, 2026 21:36
Per review, remove the explanatory inline comments on the FEATURE_DISABLED
branch (the behavior is already in the docstring) and on the hidden `ug setup`
/ `ug publish` registrations, and trim the --dry-run comment to one line.

Co-authored-by: Isaac <no-reply@databricks.com>
The no-config guidance path checks workspace admin status, which shells out to
the `databricks` binary. That binary is absent in CI, so the new dry-run test
raised FileNotFoundError there (it passed locally only because the CLI was
present). Stub the token and admin calls, matching the sibling bare-ug tests.

Co-authored-by: Isaac <no-reply@databricks.com>
…code file

The state-isolation fixture rebinds STATE_PATH and APP_DIR but not
managed_config.MANAGED_STATE_PATH, which is bound from APP_DIR at import time,
so save_managed_state wrote to the developer's real ~/.ucode/managed-state.json.
This PR's FEATURE_DISABLED change made test_feature_disabled_sets_flag_when_there_is_no_fallback
hit that unmocked write. Rebind MANAGED_STATE_PATH in the fixture, matching the
existing STATE_PATH defense-in-depth.

Co-authored-by: Isaac <no-reply@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants