perf: combos split + next config + 1-click redis + bifrost sidecar (#3932)

[KooshaPari]

Summary

Follow-up to #3932 — delivers the 5-track performance + UX workstream from that thread. After auditing upstream main, four of the five tracks are still applicable; the fifth (chatLogHelpers extraction) was already merged upstream as memoryExtraction.ts + logTruncation.ts and is dropped here.

Diff is +1,161 / −73 across 15 files, base = upstream/main @ db362b012, 1 commit ahead, 0 behind.

Changes (rolled into one commit)

PR-1: combos leaf-component extraction

• New: src/app/(dashboard)/dashboard/combos/FieldLabelWithHelp.tsx (32 LOC)
• New: src/app/(dashboard)/dashboard/combos/WeightTotalBar.tsx (66 LOC)
• New: src/app/(dashboard)/dashboard/combos/parts.ts (barrel re-export)
• New: src/app/(dashboard)/dashboard/combos/loading.tsx (Suspense skeleton, 15 LOC)
• Modified: combos/page.tsx 4,384 → 4,314 lines (−70 LOC)
  • Removed inline FieldLabelWithHelp and WeightTotalBar definitions
  • Added import { FieldLabelWithHelp, WeightTotalBar } from "./parts";
• Both extracted components are pure-presentational with zero closure dependency on CombosPage state

PR-2: next.config.mjs perf

• compress: true (gzip static assets)
• productionBrowserSourceMaps: false (skips ~30MB .map emission per build)
• experimental.optimizePackageImports for lobehub/icons, @lobehub/icons, lucide-react, date-fns, lodash, lodash-es, material-symbols, next-intl, @omniroute/open-sse
• New webpack splitChunks cacheGroups: vendor-next-intl (priority 25), vendor-fumadocs, vendor-combo-graph

PR-3: 1-click Redis launcher

• New CLI: bin/cli/commands/redis.mjs (294 LOC)
  Subcommands: up, down, status; options: --port, --name, --image, --runtime, --password, --no-pull
  Auto-detects podman then docker, pulls image if missing, uses named volume for persistence
• New GUI: src/app/(dashboard)/dashboard/settings/components/RedisLauncherPanel.tsx (172 LOC) — Start/Stop button + 3s status polling
• New API routes: /api/local/redis/{start,stop,status}
• New security guard: src/lib/security/localEndpoints.ts with loopback + bearer-token + prod opt-in
• Modified: bin/cli/commands/registry.mjs (registerRedis(program))
• Modified: bin/cli/locales/en.json (redis.description key)

PR-4: Bifrost sidecar proxy route

• New: src/app/api/v1/relay/chat/completions/bifrost/route.ts (273 LOC)
• When BIFROST_BASE_URL is set, relay traffic goes directly to the Go gateway
• Auth/rate-limit/injection-guard stay in this route (security not duplicated)
• Falls back to /api/v1/relay/chat/completions via X-Bifrost-Fallback header on sidecar timeout/failure

PR-5: DROPPED

• Upstream already has open-sse/handlers/chatCore/memoryExtraction.ts and logTruncation.ts covering the same surface area I was extracting. No need to redo.

Verification performed

• node --check on every edited .mjs/route file: clean
• python3 -m json.tool on bin/cli/locales/en.json: clean
• Inline call-site preservation grep for moved components: 10/10 for FieldLabelWithHelp, 1/1 for WeightTotalBar
• All imports verified to exist on upstream main (no orphan references)

Test plan for reviewer

1. git fetch origin feat/perf-combos-split-2026-06-20-v2
2. pnpm install && pnpm build — check that vendor-next-intl, vendor-fumadocs, vendor-combo-graph chunks split correctly
3. node bin/omniroute.mjs redis status — should print JSON state
4. node bin/omniroute.mjs redis up — should launch container via podman/docker
5. Open /dashboard/settings/resilience — RedisLauncherPanel should render and poll status every 3s

Refs

• Closes follow-up to feat(backend): Performance Improvements and ToolStack maturation #3932
• Builds on upstream/main @ db362b012 (Release v3.8.30)
• Prior PR perf: combos split + next config + 1-click redis + bifrost sidecar + chatCore helpers (#3932) #4379 closed (wrong base)

[gemini-code-assist]

Code Review

This pull request introduces a local Redis container management CLI command and a corresponding settings dashboard panel, adds local API endpoints to control the container, optimizes Next.js build performance (compression, tree-shaking, and chunk splitting), refactors dashboard combo components, and adds a high-performance sidecar proxy route for Bifrost. Feedback highlights critical issues: the CLI container startup and pull logic is buggy and inverted; the local Redis start API route uses conflicting --rm and --restart options; and the local endpoint security guard uses an unsafe global variable globalThis.__omniRequestHeaders that can cause race conditions under concurrent requests, which should be replaced with Next.js's safe headers() utility. Additionally, importing createConnection statically in the CLI command would optimize the TCP probe.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

There are two major issues in this block:

1. If the container already exists but is stopped, and --no-pull is not specified (opts.pull is true), the condition exists && !opts.pull evaluates to false. The command then falls through to docker run, which will fail because the container name is already in use.
2. The --no-pull flag logic is inverted. When --no-pull is specified, opts.pull is false, which triggers the if (!opts.pull) block and pulls the image anyway. When --no-pull is not specified, opts.pull is true, and it skips the pulling block.

We should always start the container if it exists, and only pull the image if opts.pull is not explicitly false.

  if (exists) {
    info(`Starting existing container '${name}'…`);
    try {
      await execFile(runtime, ["start", name]);
      success(`Container '${name}' started on port ${port}.`);
      return 0;
    } catch (err) {
      fail(`Failed to start existing container: ${err.message}`);
      return 1;
    }
  }

  if (opts.pull !== false) {
    info(`Checking if image '${image}' is present locally…`);
    let present = false;
    try {
      const { stdout } = await execFile(runtime, ["images", "--format", "{{.Repository}}:{{.Tag}}"]);
      present = stdout.split("\n").some((line) => line.trim() === image);
    } catch {
      // ignore — fall through to pull
    }
    if (!present) {
      info(`Image not found locally — pulling '${image}'…`);
      try {
        await execFile(runtime, ["pull", image]);
      } catch (err) {
        fail(`Failed to pull image: ${err.message}`);
        return 1;
      }
    }
  }

[gemini-code-assist]

In Docker and Podman, --rm (auto-remove on container exit) and --restart are mutually exclusive options. Attempting to run a container with both options will result in a runtime error: Conflicting options: --rm and --restart. Since this is a Redis service, we should remove --rm and keep --restart unless-stopped to ensure the container persists and restarts as expected.

    const args = [
      "run",
      "-d",
      "--name",
      CONTAINER_NAME,
      "-p",
      `${HOST_PORT}:6379`,
      "--restart",
      "unless-stopped",
      IMAGE,
    ];

[gemini-code-assist]

Using globalThis.__omniRequestHeaders to store and retrieve request-specific headers is highly unsafe in a concurrent, asynchronous Node.js environment. Concurrent requests can overwrite this global variable, leading to race conditions where a request from a non-local origin could bypass the security guard if a local request runs concurrently.

Instead of using a shared global variable, use Next.js's built-in, concurrency-safe headers() utility from next/headers which uses AsyncLocalStorage under the hood to safely isolate request context.

/**
 * Guard for /api/local/* routes.
 *
 * These endpoints shell out to the user's local Podman/Docker to manage local
 * infrastructure (Redis, Postgres, MinIO, etc.) on behalf of the GUI. They MUST
 * only respond to requests originating from the same host as the dev server.
 *
 * Trust boundary: this is the only line of defense between the public network
 * and `execFile(podman, ...)` / `execFile(docker, ...)`. If this guard is
 * missing or weak, an attacker can trigger arbitrary local CLI invocations by
 * tricking the user into loading a page that fetches `/api/local/*`.
 *
 * Rules:
 *   1. Allow requests whose `host` header matches the dev server's bind host
 *      (localhost / 127.0.0.1 / ::1) AND whose `x-forwarded-for` is absent
 *      or set to a loopback address. This blocks proxied requests from the
 *      public internet when the dev server is bound to localhost.
 *   2. In production (`NODE_ENV=production`), reject unconditionally unless
 *      OMNIROUTE_LOCAL_ENDPOINTS_ENABLED=1 is set. The flag is opt-in so
 *      accidental dev deployments do not expose the API.
 *   3. Trust-list the OmniRoute desktop app via a shared bearer token
 *      (OMNIROUTE_LOCAL_ENDPOINTS_TOKEN). The desktop app injects the header
 *      and the server verifies it.
 *
 * If you are adding a new endpoint under /api/local/* you must:
 *   - call this guard at the top of your handler
 *   - never read user-supplied input into `execFile` argv without strict
 *     allow-list validation (no shell:true, no string concatenation)
 *   - log the invocation via the audit channel so misuse is detectable
 */
import { headers } from "next/headers";

export function isLocalRequestAllowed(): { allowed: true } | { allowed: false; reason: string } {
  let requestHeaders: Headers | undefined;
  try {
    requestHeaders = headers();
  } catch {
    requestHeaders = (globalThis as { __omniRequestHeaders?: Headers }).__omniRequestHeaders;
  }

  if (requestHeaders) {
    // 1. Bearer token path (desktop app trust)
    const expected = process.env.OMNIROUTE_LOCAL_ENDPOINTS_TOKEN;
    if (expected) {
      const supplied = requestHeaders.get("authorization")?.replace(/^Bearer\s+/i, "") ?? "";
      if (supplied && constantTimeEqual(supplied, expected)) {
        return { allowed: true };
      }
    }
    // 2. Same-origin loopback path (browser dev tools)
    const host = requestHeaders.get("host") ?? "";
    const fwd = requestHeaders.get("x-forwarded-for") ?? "";
    const isLoopbackHost = /^(localhost|127\.0\.0\.1|::1)(:\d+)?$/.test(host);
    const isLoopbackFwd = fwd === "" || /^127\.|^::1$|^localhost$/.test(fwd.split(",")[0]?.trim() ?? "");
    if (isLoopbackHost && isLoopbackFwd) {
      return { allowed: true };
    }
    return { allowed: false, reason: "non-local origin" };
  }

[gemini-code-assist]

Instead of using a dynamic import inside the pingRedis function on every ping, we can import createConnection from node:net statically at the top of the file.

Suggested change

	import { spawn } from "node:child_process";
	import { promisify } from "node:util";
	import { execFile as execFileCb } from "node:child_process";
	import { spawn } from "node:child_process";
	import { promisify } from "node:util";
	import { execFile as execFileCb } from "node:child_process";
	import { createConnection } from "node:net";

[gemini-code-assist]

Use the statically imported createConnection function here to simplify the TCP probe logic and avoid dynamic import overhead.

    const socket = createConnection({ port: Number(port), host: "127.0.0.1" });
    const timeout = setTimeout(() => {
      socket.destroy();
      resolve(false);
    }, 1500);
    socket.once("connect", () => {
      clearTimeout(timeout);
      socket.end();
      resolve(true);
    });
    socket.once("error", () => {
      clearTimeout(timeout);
      resolve(false);
    });

[diegosouzapw]

Merged into release/v3.8.31 🎉 Thanks @KooshaPari for the substantial perf work!

We pushed a few review fixes to your branch before merging (co-authored):

• Redis routes: dropped the conflicting --rm (it clashes with --restart unless-stopped — Docker/Podman reject the run); errors now go through sanitizeErrorMessage (Hard Rule fix(ui): fix Select dropdown dark theme inconsistency #12).
• UI: RedisLauncherPanel now calls /start + /stop (matched the real route names — the old /up//down 404'd).
• localEndpoints.ts: corrected the header — the authoritative gate is managementPolicy (socket-IP loopback enforcement via routeGuard's LOCAL_ONLY_API_PREFIXES); the in-route guard is documented as best-effort defense-in-depth.
• Bifrost: added a Zod request schema + fixed dangling @see docs.
• Fixed two pre-existing red tests (IPv6 [::1] bracketed-host match + the CLI option-flag mock).

Live VPS validation (Rule #18) on 192.168.0.15 (build b44d79ea6, v3.8.31):

# Direct args proof of the --rm fix:
OLD (--rm + --restart) -> docker: 'conflicting options: cannot specify both --restart and --rm'  (container does NOT start)
NEW (no --rm)          -> container starts; redis-cli ping -> PONG

# Full HTTP route (flag enabled, authed, loopback):
POST /api/local/redis/start  -> 200 {ok:true, runtime:docker, name:omniroute-redis, port:6379, stdout:<id>}
GET  /api/local/redis/status -> 200 {exists:true, running:true, reachable:true}   (docker ps: omniroute-redis Up)
POST /api/local/redis/stop   -> 200 {ok:true}
# flag disabled again -> route correctly re-gated: 403 'disabled in production'

The route classification, loopback/auth/production gating, and the container lifecycle all check out live. Ships in the next release.