fix(frontend): fix compute rivet run url

[abcxff]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[abcxff]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix: get rid of old hub.rivet.dev references #5123
• fix(frontend): onboarding prompts #5122
• fix(frontend): fix compute rivet run url #5121 👈 (View in Graphite)
• feat(frontend): redesign onboarding wizard #5116
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[railway-app]

🚅 Deployed to the rivet-pr-5121 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
kitchen-sink	❌ Build Failed (View Logs)	Web	Jun 2, 2026 at 7:38 pm
website	😴 Sleeping (View Logs)	Web	Jun 1, 2026 at 8:55 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	Jun 1, 2026 at 8:49 pm
ladle	✅ Success (View Logs)	Web	Jun 1, 2026 at 8:47 pm
mcp-hub	✅ Success (View Logs)	Web	Jun 1, 2026 at 8:41 pm
frontend-inspector	❌ Build Failed (View Logs)	Web	Jun 1, 2026 at 8:39 pm

[claude]

PR Review: fix(frontend): fix compute rivet run url

Files changed: 4 | Net diff: +12 / -12

Overview

This PR does two independent things:

1. Refactors the `rivet.run` URL computation — extracts duplicated inline URL-building logic from `actors-grid.tsx` and `getting-started.tsx` into a shared `getRivetRunUrl()` helper in `env.ts`. The key behavioral change is that staging detection switches from reading the `DEPLOYMENT_TYPE` build-time env var to inspecting `window.location.hostname` at runtime.

2. Adds a null-guard in `feedback-button.tsx` — changes the keyboard handler to guard against a null/undefined `e.key`.

---

Bug (blocking): Inverted null-guard in `feedback-button.tsx`

-if (e.key.toLowerCase() !== "f") return;
+if (!e.key && e.key.toLowerCase() !== "f") return;

The new condition is logically wrong. When `e.key` is falsy, `!e.key` is `true` but `e.key.toLowerCase()` throws `TypeError: Cannot read properties of undefined` — the very crash this is meant to prevent — because the `&&` does not short-circuit when its left operand is truthy. And when `e.key` is falsy, `!e.key && ...` evaluates to `false` (short-circuits), so `return` is skipped and the handler proceeds to `e.preventDefault(); setOpen(true)`, incorrectly opening the feedback popover for any synthetic event with no key.

The correct guard is:

if (!e.key || e.key.toLowerCase() !== "f") return;

This exits early (does nothing) when `e.key` is falsy, and also exits when the key is not `"f"`. This matches the original intent.

---

Correctness concern: Staging detection strategy change

The original code used the build-time `DEPLOYMENT_TYPE` env var (values: `"staging"` | `"production"`) to pick the URL subdomain. The new code uses `window.location.hostname` matching `/(^|.)staging.rivet.dev$/`.

The behavioral difference: the old approach was an explicit configuration (you set `DEPLOYMENT_TYPE=production` in the build pipeline), while the new approach infers staging from the hostname the browser is currently on.

This is a reasonable approach for a URL that is displayed to users (the rivet.run deployment URL), but there is one edge case to consider: the `DEPLOYMENT_TYPE` env var still exists in the schema (as `optional()`) and is still read in other parts of the codebase (e.g., `getting-started.tsx` line 1548-1550 was not updated in this PR — the worktree still contains the old inline code there). Double-check that the `getting-started.tsx` `FrontendSetup` component was also migrated. The diff shows it was changed, but the `getting-started.tsx` import line now reads `import { cloudEnv, engineEnv, getRivetRunUrl } from "@/lib/env"` while the old `cloudEnv` import is still retained — confirm there are no remaining references to the old `DEPLOYMENT_TYPE`-based URL logic in that file.

---

Minor: `isStagingHost` SSR guard

export const isStagingHost = () =>
  typeof window !== "undefined" &&
  /(^|\.)staging\.rivet\.dev$/.test(window.location.hostname);

The `typeof window !== "undefined"` guard is good defensive practice, though the dashboard is a pure SPA and does not run server-side. No change needed, just noting it is correct.

---

Minor: Regex correctness

The pattern `/(^|.)staging.rivet.dev$/` correctly matches:

• `staging.rivet.dev` (exact match)
• `hub.staging.rivet.dev` (subdomain)

And does not match `notstaging.rivet.dev` (the `(^|.))` anchor prevents false positives). This is correct.

---

Summary

Issue	Severity	File
Inverted null-guard — opens popover on keyless events, crashes on falsy `e.key`	Blocking	`feedback-button.tsx`
Verify `getting-started.tsx` migration is complete (no remaining `DEPLOYMENT_TYPE`-based URL build)	Needs confirmation	`getting-started.tsx`
Staging detection change (env var → hostname) is a semantic shift	Informational	`env.ts`

The `getRivetRunUrl` extraction is clean and the deduplication is valuable. The `feedback-button.tsx` fix needs the condition operator corrected from `&&` to `||` before this is safe to merge.

[jog1t]

I wonder if this should be returned from the cloud api instead,’like good old times with hub. Like /metadata for cloud api.