mirror of
https://github.com/BigBodyCobain/Shadowbroker.git
synced 2026-05-27 09:32:28 +02:00
Shadowbroker
d0299fc0a0
Vitest's default per-test timeout is 5s. That's plenty for tests that exercise pure functions or even simple JSX, but the heavier React component trees we render under jsdom — MessagesView, GateView, Wormhole contact flows — consistently measure 6-10s on GitHub Actions' shared Node workers under load. Concrete flake history that drove this bump (none were real product bugs — all were CI load racing the 5s ceiling on findByText / waitFor against React reconciliation): PR #226 messagesViewFirstContact > removes approved contact PR #237 (same) PR #261 (same) PR #262 (same) ← worst: fired on post-merge Docker Publish run, prevented the AIS SPKI security fix's image from being published to GHCR until PR #263 cumulatively re-published it. Real security-fix-shipping risk. PR #264 fixed messagesViewFirstContact specifically with waitFor PR #265 messagesViewFirstContact > legacy handle-only addresses AND gateCompatDecryptUx > browser-local gate runtime AND failed on the rerun too — confirming the flake class is broader than the one test we deflaked. The deflake in PR #264 was too surgical — it addressed one specific test out of a class of similarly-flaky CI-load-sensitive sites. This PR addresses the root cause at the config layer instead of playing whack-a-mole. Why 15s specifically: 3x the default. Headroom for routine CI slowness without masking real "test never settles" bugs (those would still time out, just three rounds later). Individual tests can still pin their own tighter timeout via the third arg to `it()`. Also bumps hookTimeout to 15s — beforeEach/afterEach setup for the same heavier component tests has the same CI-load sensitivity. User-facing impact: zero. This is dev pipeline infrastructure. End users never see test timeouts. The cost is theoretical: a buggy test that genuinely never resolves now takes 15s to declare failure instead of 5s. In practice that's negligible because the suite runs once per CI invocation and tests don't usually deadlock. Validation: Local full vitest run → 707 passed, 72 files, 10.36s wall clock (same speed as before — we only changed how long we WAIT for slow tests, not how fast tests actually run) Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
ShadowBroker Frontend
Next.js 16 dashboard with MapLibre GL, Cesium, and Framer Motion.
Development
npm install
npm run dev # http://localhost:3000
API URL Configuration
The frontend needs to reach the backend (default port 8000). Resolution order:
NEXT_PUBLIC_API_URLenv var — if set, used as-is (build-time, baked by Next.js)- Server-side (SSR) — falls back to
http://localhost:8000 - Client-side (browser) — auto-detects using
window.location.hostname:8000
Common scenarios
| Scenario | Action needed |
|---|---|
Local dev (localhost:3000 + localhost:8000) |
None — auto-detected |
LAN access (192.168.x.x:3000) |
None — auto-detected from browser hostname |
| Public deploy (same host, port 8000) | None — auto-detected |
Backend on different port (e.g. 9096) |
Set NEXT_PUBLIC_API_URL=http://host:9096 before build |
| Backend on different host | Set NEXT_PUBLIC_API_URL=http://backend-host:8000 before build |
Behind reverse proxy (e.g. /api path) |
Set NEXT_PUBLIC_API_URL=https://yourdomain.com before build |
Setting the variable
# Shell (Linux/macOS)
NEXT_PUBLIC_API_URL=http://myserver:8000 npm run build
# PowerShell (Windows)
$env:NEXT_PUBLIC_API_URL="http://myserver:8000"; npm run build
# Docker Compose (set in .env file next to docker-compose.yml)
NEXT_PUBLIC_API_URL=http://myserver:8000
Note: This is a build-time variable. Changing it requires rebuilding the frontend.
Theming
Dark mode is the default. A light/dark toggle is available in the left panel toolbar.
Theme preference is persisted in localStorage as sb-theme and applied via
data-theme attribute on <html>. CSS variables in globals.css define all
structural colors for both themes.