Repository navigation
automations create returns "Not found" and hosts list is empty while host service is healthy #6415
Description
What happened
Every superset automations create variant fails with Error: Not found.
superset status reports the host running and healthy (hostId present), and superset ws list returns workspaces referencing that same hostId — but superset hosts list returns []. superset automations list works and returns [], so the API is reachable and it is not a blanket auth failure.
CLI is 1.20.2 (superset update --check says up to date).
Steps to reproduce
superset status-> running: true, healthy: true, hostId presentsuperset hosts list->[]superset automations list->[](works)superset automations create --name "Hello World test" --rrule "FREQ=DAILY;BYHOUR=9;BYMINUTE=0" --timezone America/Sao_Paulo --project <project id> --agent claude --prompt "hi"->Error: Not found- Same
Error: Not foundfor each of: adding--host <hostId from status>;--agent <agent instance uuid>instead of theclaudepreset;--workspace <existing workspace id>; and omitting project/workspace entirely (project-less mode)
Suspicion: the host is not registered server-side (hence the empty hosts list), and automation creation 404s because it cannot resolve a host to run on. The error message gives no indication of which resource was not found.
Environment
- superset 1.20.2
- Darwin arm64 (macOS)
Activity
github-actions commentedon Aug 13, 2026
Summary
Every
automations createvariant fails because the cloudautomation.createprocedure rejects the automation's target host, and the CLI collapses that into the stringError: Not found. The three observations that look contradictory are all consistent with one state: the machine has a running, locally-healthy host service that was never (or is no longer) registered inv2_hostsfor your active organization.superset statusandsuperset ws listare purely local reads and pass regardless of cloud registration;hosts listandautomations createare the two calls that actually need the cloud row, and both fail. The "no indication of which resource" part is a separate, real CLI bug: the server does send"Host not found"and the CLI throws it away.Affected code
1. The CLI discards the server's error message for every
NOT_FOUND:packages/cli-framework/src/runner.ts:89-91Note that
UNAUTHORIZEDandFETCH_ERRORget hints and everything else printserror.message— onlyNOT_FOUNDis blanked. This is why you saw no resource name.2. The only
NOT_FOUNDreachable in your project-less run is the host check:packages/trpc/src/router/automation/automation.ts:210-221callsverifyHostAccesswheneverinput.targetHostIdis set, andverifyHostAccess(automation.ts:40-61) throwsNOT_FOUND: "Host not found"when nov2_hostsrow matches(organizationId, machineId).3. The CLI always sends
targetHostId, even in session mode — which is why omitting--project/--workspacedid not help:packages/cli/src/commands/automations/resolveAutomationTarget.ts:22and
resolveAutomationTarget.ts:51-55returns early for session mode without validating the host at all, so the failure is deferred to the server's 404.Suspected root cause
Error: Not found(rather thanYou don't have access to this host, which isFORBIDDENatautomation.ts:75-80and would have printed its message) narrows this to: nov2_hostsrow exists for(active org, your machineId). It is not a missingv2_users_hostsgrant, and not auth —automations listprovesrequireActiveOrgMembershippasses.The
v2_hostsrow is only ever written byhost.ensure(packages/trpc/src/router/host/host.ts:94-158), and that is called from exactly one place —packages/host-service/src/tunnel/connect.ts:65-69. That call site swallows failures:Two things make this silent and consistent with your symptoms:
superset startdaemonizes withstdio: "ignore"(packages/cli/src/lib/host/spawn.ts:108), so thatconsole.errorgoes nowhere, and the readiness gate ispollHealthon the local port only (spawn.ts:131) — cloud registration is not part of it.superset statusreadsrunning/healthyfrom the local manifest plus alocalhost/trpc/health.checkfetch, andhostIdfrom localgetHostId()(packages/cli/src/commands/status/command.ts:52-101). It never asserts cloud registration. The one signal it does surface ishostName, which comes fromhost.list(status/command.ts:27-38) — if yourstatusoutput showedhost 1a2b3c4d… runninginstead of a machine name, that is the same missing row.ws listgoes to the host service directly over the local manifest (packages/cli/src/lib/host-workspaces/workspacesOnHost.ts:21-32→packages/cli/src/lib/host-target/resolveHostTarget.ts:46-75). Hosts own workspace records, so workspaces referencing thathostIdprove nothing about the cloud table. Your inference here was right.Most likely trigger for the failed
host.ensure: aFORBIDDENfromhost.ts:103-108(the host service's JWTorganizationIdsclaim not containing the org it was started for — e.g. a stale token after an org switch/invite) or a transient API failure at start time, either way swallowed and never retried for the lifetime of the process.Reproduction
Manual, on the reporter's machine (also serves as confirmation of the diagnosis):
superset status— check whetherhostNameisnullin--jsonoutput. Null +running: trueis the bug state.superset stop, then run the host service non-daemonized (superset startwithout daemonizing, orSUPERSET_HOST_BIN=… superset-hostwith the same env) and look for either[host-service] registered as host <id>or[host-service] failed to register/connect relay: …. The latter's payload is the real error.superset hosts listshould show the machine andautomations createshould succeed unchanged.Automated sketch:
packages/trpc: callautomation.createwithtargetHostIdset to a machineId that has nov2_hostsrow in the caller's active org, with no project/workspace, and assertTRPCErrorcode === "NOT_FOUND"/message === "Host not found". This pins the exact path taken by the project-less variant.packages/cli-framework: unit-testhandleErrorwith{ data: { code: "NOT_FOUND" }, message: "Host not found" }and assert stderr containsHost not found. Fails today.Suggested fix direction
runner.ts:89-91): print the server message, keeping the generic text only as a fallback:verifyHostAccess(automation.ts:57-61) should name the host:Host ${hostId} is not registered in this organization.resolveAutomationTargetshould validate the target host againstapi.host.listin all branches (including the session-mode early return atresolveAutomationTarget.ts:51-55) and raise aCLIErrorwith a hint like"This machine isn't registered in the cloud — run: superset stop && superset start". That converts a 404 from the API into a fixable message at the point the user can act on it.host.ensurefailure fromconnectRelay(connect.ts:91-94) as host-service state thathealth.check/superset statuscan report (e.g. acloudRegistered: falsefield, and a warning line instatuswhenhostNameis null), retry registration on the tunnel's reconnect loop, and write daemon stdio to a log file instead of"ignore"(spawn.ts:108) so this class of failure is diagnosable at all.Items 1 and 2 are small and independent of the underlying registration bug; they're worth landing regardless, since they would have made this issue self-diagnosing.
Kitenite commentedon Aug 13, 2026
Confirmed the diagnosis above end-to-end (reproduced the exact
Error: Not foundby pointing--hostat an unregistered machineId, and found a live instance of the silent-registration failure in local logs). One additional finding that makes this worse than the triage suggests:host-service.logis only written by the desktop spawner (host-service-coordinator.tspipes child stdio to the file). The CLI daemon spawns withstdio: "ignore"— so for a CLI-managed host like this report, the[host-service] failed to register/connect relay:error is not recorded anywhere at all.Here's the fix design, split into two PRs so the self-diagnosing part lands immediately:
PR 1 — make the failure self-diagnosing (small, no behavior change)
Stop blanking NOT_FOUND in the CLI —
packages/cli-framework/src/runner.ts: print the server's message, keeping the generic text only as a fallback:UNAUTHORIZEDandFETCH_ERRORalready get useful text; NOT_FOUND is the only blanked branch.Make the server message name the resource —
verifyHostAccessinpackages/trpc/src/router/automation/automation.ts:Host <machineId> is not registered in this organization. (FORBIDDEN branch stays as-is; its message already survives to the terminal.)CLI preflight in
resolveAutomationTarget— validate the target host againstapi.host.listin all branches, including the session-mode early return (today it returns without touching the host at all, which is why omitting--project/--workspacedidn't help). On miss, raise aCLIErrorwith the actionable hint:Tests: unit-test
handleErrorwith{data:{code:"NOT_FOUND"}, message:"Host not found"}asserting the message survives (fails today), and a trpc test pinningautomation.create→ NOT_FOUND for an unregisteredtargetHostIdwith no project/workspace.PR 2 — stop registration failing silently
Retry
host.ensureinstead of one-shot —packages/host-service/src/tunnel/connect.tscurrently tries once at boot and gives up for the lifetime of the process; a transient API blip at startup permanently strands the host unregistered. Change to a backoff loop (30s doubling, capped at 5min, retry indefinitely) and keep tunnel connect downstream of a successful ensure.Expose registration state locally — host-service keeps
{ cloudRegistered: boolean, lastRegistrationError: string | null, lastAttemptAt }and returns it from the local health router (health.checktoday returns only{status:"ok"}).superset statussurfaces it — whenrunning: truebut the host isn't cloud-registered, say so explicitly instead of silently printinghostName: null:statusalready callshost.listfor the name and drops the null — the signal is there today, unused. Keep thehostName === nullheuristic as fallback for old host-services that don't have the new health field.CLI daemon logs to a file —
packages/cli/src/lib/host/spawn.ts: replacestdio: "ignore"with appending to~/.superset/host/<org>/host-service.log, same path + rotation convention the desktop coordinator already uses, so this class of failure is diagnosable on CLI-only installs.@lnmunhoz in the meantime,
superset stop && superset startshould re-attempt registration; if it still doesn't show up insuperset hosts list, the underlyinghost.ensureerror (likely auth/org-membership) will be visible if you run the host in the foreground.Kitenite commentedon Aug 13, 2026
Fix is up: #6417 (all of the design above in one PR, verified end-to-end by staging this exact failure state and driving both the CLI and the desktop app through it).
What changes for this report:
superset automations createwill tell you what's actually wrong, at the point you can act on it:superset statusnow warns when the host is running but not cloud-registered (with the underlying registration error), instead of reporting only local health.~/.superset/host/<org>/host-service.log(previously daemon output was discarded, which is why nothing on your machine recorded the original failure).@lnmunhoz until this ships in a release:
superset stop && superset startre-attempts registration. Ifsuperset hosts liststill comes back empty after that, the underlying error will now be visible if you run the host in the foreground — or share the output of:(if that file doesn't exist, that's the logging gap this PR also fixes — running
superset startwithout daemonizing will show the error directly).fix(cli,host-service): surface host cloud-registration failures inste…
lnmunhoz commentedon Aug 13, 2026
@Kitenite Tried a couple of times, got nothing.
➜ pollen-heaven git:(main) superset stop && superset start
➜ pollen-heaven git:(main) grep "failed to register" ~/.superset/host/*/host-service.log
➜ pollen-heaven git:(main) superset hosts list
No results.
➜ pollen-heaven git:(main)
Full logs: