You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "me2seeks (via GitHub)" <gi...@apache.org> on 2026/09/07 05:49:38 UTC
[I] bug(cli): managed default root blocks local TUI with nonexistent Host profile recovery hint [maka]
me2seeks opened a new issue, #4959:
URL: https://github.com/apache/maka/issues/4959
## Problem
Running plain `maka` locally inside WSL exits with a raw `RuntimeHostStartupError: MANAGED_ROOT_REQUIRES_OPERATOR` when the default State Root belongs to an on-demand managed deployment and no Host is running. The error instructs the user to activate through a configured Host profile, but the local profile catalog contains only the built-in `local` profile. There is no actionable recovery route in the error.
The managed-launch ownership guard is correct. The bug is the local CLI startup/recovery UX: it attempts an unmanaged candidate and then directs the user to a profile that does not exist, rather than exposing the appropriate operator-owned activation path or concrete setup/recovery instructions.
## Verified environment and reproduction
- WSL2 Linux, Node managed through mise; source CLI checkout at `b06eb02e6aecbc56e003439ce61b371baf0b4fc9`, matching upstream main at investigation time.
- Repository cwd: `/home/me2seeks/maka-agent`. The affected State Root is separately located at `~/.config/Maka/workspaces/default`.
- Existing managed deployment record is `state: active`, `lifecycle: { mode: on_demand, availability: activation }`, with reconciliation triggered by activation. It selects an exact npm package, version `0.2.0-dev.8.20260830`.
- No Runtime Host process was running.
- `maka runtime-host profile list` returns only `{ id: "local", name: "Local", kind: "local" }`.
- `maka runtime-host service status --json` reports `not_installed`. This is an on-demand deployment, so absence of a systemd service is not itself evidence of corruption.
- Running `node packages/cli/dist/cli.js` from the checkout reproduces the reported error and exits 1.
```text
RuntimeHostStartupError: This workspace is managed by a Runtime Host operator. Activate it through the configured Host profile. Diagnostic code: MANAGED_ROOT_REQUIRES_OPERATOR.
at runtimeHostStartupError (.../runtime-host/dist/client/startup-error.js:41:20)
at connect (.../cli/dist/runtime-host-cli-context.js:115:19)
at async connectRuntimeHostCliConnection (.../cli/dist/runtime-host-cli-context.js:129:29)
at async connectRuntimeHostCli (.../cli/dist/runtime-host-cli-context.js:57:21)
at async createRuntimeHostTuiContext (.../cli/dist/runtime-host-tui-context.js:33:23)
at async createTuiContextWithHostConflictPrompt (.../cli/dist/runtime-host-tui-command.js:117:20)
at async runRuntimeHostTui (.../cli/dist/runtime-host-tui-command.js:44:19)
```
## Code path
- `packages/cli/src/runtime-host-cli-context.ts`: `resolveHostProfile` chooses built-in local when no profile is supplied; the local connection invokes `connectOrSpawnRuntimeHost`.
- `packages/runtime-host/src/operator/managed-deployment.ts`: `runtimeHostManagedLaunchRejection` correctly returns `managed_root_requires_operator` when a managed configuration exists but no managed launch claim is supplied.
- `packages/runtime-host/src/client/startup-error.ts`: the message assumes a configured profile exists.
- `packages/cli/src/runtime-host-tui-command.ts`: this startup failure escapes the existing onboarding/conflict handling as a raw stack trace.
## Expected behavior / acceptance
1. Recognize this managed default-root case and expose an operator-owned activation/recovery route. If safe automatic activation is supported, delegate to the existing operator and preserve exact deployment identity; do not grant ordinary election takeover authority.
2. When user action is required, identify the affected data root and give an actually usable command or setup action. Do not assume a saved profile exists.
3. Handle this expected startup condition without dumping an internal stack trace.
4. Cover the stopped on-demand deployment plus local-only profile catalog case. Preserve the managed-launch guard, stored sessions, and deployment record.
The historical setup operation that created this deployment has not been established; no claim is made that setup corrupted the record. No deployment configuration or session data was deleted or changed during diagnosis.
Related: #4792, #3709, #3245. This is a concrete cold-start/recovery reproduction, not a request to bypass lifecycle ownership or replace the broader reconciliation work.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] bug(cli): managed default root blocks local TUI with nonexistent Host profile recovery hint [maka]
Posted by "me2seeks (via GitHub)" <gi...@apache.org>.
me2seeks closed issue #4959: bug(cli): managed default root blocks local TUI with nonexistent Host profile recovery hint
URL: https://github.com/apache/maka/issues/4959
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org