fix: guard /managed-workers routes in self-hosted mode by HirenGajjar · Pull Request #3900 · hatchet-dev/hatchet

HirenGajjar · 2026-05-12T19:03:13Z

What

Added a useCloud() guard to the managed-workers index and create pages.
In self-hosted (Lite) mode both routes now return a 404 instead of
causing an infinite loading screen.

Why

isCloudEnabled is false in self-hosted mode. Without the guard, the
page attempted to call cloud-only billing and compute APIs that don't
exist, resulting in an infinite spinner and a flood of failed requests.

Changes

pages/main/v1/managed-workers/index.tsx — added cloud guard
pages/main/v1/managed-workers/create/index.tsx — added cloud guard

Testing

Build the Vite app and launch Hatchet Lite per the steps in #3896.
Navigating to /managed-workers and /managed-workers/create now
returns a 404 page instead of the infinite loading screen.

In self-hosted (Lite) mode, navigating to /managed-workers caused an infinite loading screen because the page attempted to fetch cloud-only billing and compute APIs that don't exist in self-hosted deployments. Added a useCloud() guard to both the managed-workers index and create pages. When isCloudLoading is true a spinner is shown; when isCloudEnabled is false a 404 page is returned instead, preventing the broken loading state. Fixes hatchet-dev#3896

vercel · 2026-05-12T19:03:19Z

@HirenGajjar is attempting to deploy a commit to the Hatchet Team on Vercel.

A member of the Team first needs to authorize it.

promptless-for-oss · 2026-05-12T19:07:26Z

Promptless prepared a documentation update related to this change.

Triggered by PR #3900

Added a "Cloud-only features" section to the cloud-vs-oss.mdx page that explicitly documents Managed Compute as a cloud-only feature. This clarifies that self-hosted users will see a 404 when attempting to access these routes.

Review: Document cloud-only features for self-hosted users

gregfurman

Quite a few comments that are polluting the diff IMO. Think you should run task fmt-app to fix all these linting issues.

Also, perhaps we use custom error messaging here instead of the 404 approach 🤔 Wdyt of instead creating a gate component that we can use to wrap these managed worker exports? i.e

export function ManagedWorkersGate({ children }: PropsWithChildren) {
  const { cloud, featureFlags, isCloudEnabled } = useCloud();
  const managedWorkerEnabled = featureFlags?.['managed-worker'] === 'true';

  if (isCloudEnabled && !cloud) {
    return null;
  }

  if (managedWorkerEnabled) {
    return <>{children}</>;
  }

  if (!isCloudEnabled) {
    // create a new ErrorPageLayout with details on why page can't be accessed
    return <ErrorPageLayout>...</ErrorPageLayout>

Which can be used like:

// renamed the original ManagedWorkers to ManagedWorkersImpl 
// ...

export default function ManagedWorkers() {
  return <ManagedWorkersGate>{ManagedWorkersImpl()}</ManagedWorkersGate>
}

gregfurman · 2026-05-14T13:55:54Z

+  // ── Render ──────────────────────────────────────────────────────────────
+


Suggested change

// ── Render ──────────────────────────────────────────────────────────────

gregfurman · 2026-05-14T13:56:33Z

  };

-  // Only show BillingRequired if there are no managed workers AND billing is required
+  // ── Derived values (not hooks) ──────────────────────────────────────────


Suggested change

// ── Derived values (not hooks) ──────────────────────────────────────────

gregfurman · 2026-05-14T13:56:52Z

+  // ── Hooks (must all be called unconditionally, before any early returns) ──
+


Suggested change

// ── Hooks (must all be called unconditionally, before any early returns) ──

Replace inline useCloud() checks with a reusable ManagedWorkersGate component that handles all three cases: - cloud enabled but metadata still loading: render nothing - managed-worker feature flag enabled: render children - self-hosted mode: render ErrorPageLayout with descriptive message Addresses review feedback on PR hatchet-dev#3900

gregfurman

Can we remove some of these unnecessary headers and revert unnecessary changes? The diff is probably larger than it needs to be tbh

Also, Can we apply this new gated component approach to the remainder of components in the managed-workers dir?

gregfurman · 2026-05-15T17:36:00Z


  const [portalLoading, setPortalLoading] = useState(false);
  const [fieldErrors, setFieldErrors] = useState<Record<string, string>>({});
+


🧹

Suggested change

gregfurman · 2026-05-15T17:36:13Z


-export default function CreateWorker() {
+function CreateWorkerImpl() {
+  // ── Hooks ────────────────────────────────────────────────────────────────


🧹

Suggested change

// ── Hooks ────────────────────────────────────────────────────────────────

gregfurman · 2026-05-15T17:36:33Z

+      });
+    },
+    onError: handleApiError,
+  });


Why has this moved?

gregfurman · 2026-05-15T17:36:44Z

+    onError: handleApiError,
+  });
+
+  // ── Derived values ───────────────────────────────────────────────────────


🧹

Suggested change

// ── Derived values ───────────────────────────────────────────────────────

gregfurman · 2026-05-15T17:36:56Z

-    },
-    onError: handleApiError,
-  });
+  // ── Early returns ─────────────────────────────────────────────────────────


🧹

Suggested change

// ── Early returns ─────────────────────────────────────────────────────────

gregfurman · 2026-05-15T17:37:05Z

+  // ── Hooks ────────────────────────────────────────────────────────────────
+


🧹

Suggested change

// ── Hooks ────────────────────────────────────────────────────────────────

gregfurman · 2026-05-15T17:37:39Z

+  const { handleApiError } = useApiError({});
+
+  // ── Derived values ───────────────────────────────────────────────────────
+
+  const workerPoolCount = listManagedWorkersQuery.data?.rows?.length || 0;
+  const [canCreateMoreWorkerPools] = can(
+    managedCompute.canCreateWorkerPool(workerPoolCount),
+  );


Same Q as above. Why has this moved?

gregfurman · 2026-05-15T17:37:51Z


+  const { handleApiError } = useApiError({});
+
+  // ── Derived values ───────────────────────────────────────────────────────


🧹

Suggested change

// ── Derived values ───────────────────────────────────────────────────────

- Remove unnecessary section comments and revert code reordering - Apply ManagedWorkersGate to demo-template and $managed-worker pages - Restore original comments and structure in all modified files Addresses review feedback on PR hatchet-dev#3900

gregfurman

This is looking great! Think we should add a fallback case for if managed compute isn't enabled but someone is running in hatchet cloud.

Otherwise, would just like to double-check with the team on the copy used in the error messages.

In the meantime, could you perhaps add screenshots of this new modal in action to the PR description? Also if you could update it to reflect the latest changes that'd be brilliant 🙏

gregfurman · 2026-05-18T11:18:48Z

+  const navigate = useNavigate();
+  const { tenantId } = useCurrentTenantId();
+
+  // Cloud enabled but metadata not yet loaded


🧹

Suggested change

// Cloud enabled but metadata not yet loaded

gregfurman · 2026-05-18T11:19:01Z

+    return null;
+  }
+
+  // Feature flag explicitly enables managed workers


🧹

Suggested change

// Feature flag explicitly enables managed workers

gregfurman · 2026-05-18T11:19:07Z

+    return <>{children}</>;
+  }
+
+  // Self-hosted mode — show informative message


Suggested change

// Self-hosted mode — show informative message

gregfurman · 2026-05-18T11:25:01Z

+    );
+  }
+
+  return null;


Can we fallback to an error component if we try to access this but the feature flag for managed-worker is not enabled? Doesn't have to be this verbatim since I used some extra iconography + buttons but am thinking something to this extent

return ( <ErrorPageLayout icon={<LifeBuoy className="h-5 w-5" />} title="Managed Workers not enabled" description="Managed Workers aren't enabled by default for your tenant. Contact support for more information." actions={ <> <Button leftIcon={<Mail className="h-4 w-4" />} onClick={() => window.open(`mailto:${HATCHET_SUPPORT_ADDRESS}`, '_blank') } > Contact us </Button> <Button leftIcon={<Undo2 className="h-4 w-4" />} variant="outline" onClick={() => window.history.back()} > Go back </Button> </> } /> );

gregfurman · 2026-05-18T11:27:39Z

+            onClick={() =>
+              navigate({
+                to: appRoutes.tenantRunsRoute.to,
+                params: { tenant: tenantId },
+              })


Let's rather allow for an undo to the previous window instead of /runs and use the Undo2 icon (like we do elsewhere) i.e

Assuming theUndo2 is imported from lucide-react:

Suggested change

onClick={() =>

navigate({

to: appRoutes.tenantRunsRoute.to,

params: { tenant: tenantId },

})

leftIcon={<Undo2 className="h-4 w-4" />}

variant="outline"

onClick={() => window.history.back()}

gregfurman · 2026-05-18T11:34:15Z

+      <ErrorPageLayout
+        icon={<CloudIcon className="h-5 w-5" />}
+        title="Managed Compute is not available"
+        description="Managed Compute is a cloud-only feature and is not supported in self-hosted deployments. Sign up for Hatchet Cloud to access this feature."


Should we be linking directly to the cloud offering here? Unsure how much we'd like to do this in the OSS offering though. Wdyt @abelanger5?

i.e

- Replace navigate-to-runs button with window.history.back() + Undo2 icon - Add fallback ErrorPageLayout for cloud users without managed-worker feature flag - Remove unnecessary useNavigate/useCurrentTenantId/appRoutes from gate Addresses review feedback on PR hatchet-dev#3900

HirenGajjar · 2026-05-18T17:44:27Z

I was unable to run the dev frontend locally due to a pre-existing missing @/lib/generated/docs file that blocks Vite from starting. Happy to add screenshots once that's resolved, or if you can point me to the correct generation step. The gate component follows the same ErrorPageLayout pattern used in tenant-forbidden.tsx and not-found.tsx so the visual output should be consistent with those.

gregfurman · 2026-05-18T18:51:06Z

I was unable to run the dev frontend locally due to a pre-existing missing @/lib/generated/docs file that blocks Vite from starting.

Have you not run this locally? How were you able to test that everything rendered without error?

You can see our CONTRIBUTING.md for details on how to get your local environment setup.

gregfurman requested changes May 14, 2026

View reviewed changes

gregfurman requested changes May 15, 2026

View reviewed changes

gregfurman requested changes May 18, 2026

View reviewed changes

		// ── Render ──────────────────────────────────────────────────────────────

		// ── Hooks (must all be called unconditionally, before any early returns) ──


		const [portalLoading, setPortalLoading] = useState(false);
		const [fieldErrors, setFieldErrors] = useState<Record<string, string>>({});

		// ── Hooks ────────────────────────────────────────────────────────────────


		const { handleApiError } = useApiError({});

		// ── Derived values ───────────────────────────────────────────────────────

Conversation

HirenGajjar commented May 12, 2026

What

Why

Changes

Testing

Uh oh!

vercel Bot commented May 12, 2026

Uh oh!

promptless-for-oss commented May 12, 2026

Uh oh!

gregfurman left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gregfurman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gregfurman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HirenGajjar commented May 18, 2026

Uh oh!

gregfurman commented May 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

gregfurman left a comment •

edited

Loading