Axon 911 Frontend Docs
    Loading navigation…
U
User
Switch to light mode
  1. Working With Data
  3. Axonmundi
  5. Testing Dev Router

Test against the dev router

Call the dev Cosmo router with a real token, check subscriptions, and point a local responder at it

These steps call the dev Cosmo router with your own token. The router needs no VPN. Steven Noland verified these steps on Nov 2: a Keycloak token, introspection returning 200, currentUser returning 401 without a token and 200 with one, a WebSocket connection_ack, and a live userNotification event in the responder.
Set the router URL once. It is the one dev GraphQL endpoint, the Cosmo router's dev URL from AxonMundi onboarding:
  1. Get a token. Only a Carbyne Keycloak token works. Okta and Doorkeeper tokens get a 401 or empty response. The auth host shows Keycloak only for client=axon-proto with a console, switchboard, wallboard or localhost returnTo, for example https://auth.ng911.dev/login?client=axon-proto&returnTo=https%3A%2F%2Fwallboard.ng911.dev%2F. Where Okta shows too, pick Keycloak. Sign in with the Keycloak account you were provisioned with (UX Core uses +uxcore@axon.com aliases), not your regular Okta email. Then open https://auth.ng911.dev/api/auth/session?client=axon-proto and export the accessToken:
    Check the token's claims:
    • iss is https://iam-service-dev-eu-west-1.carbyneapi-dev.com/auth/realms/carbyne.
    • azp is c-operator-client.
    • scope includes prepared-claims.
    • prepared_user_id is present.
    The token lasts about 4 hours.
    Do not use ?client=responder: it returns a Doorkeeper token. See Authentication for which tokens the router accepts. The account's email must match a Prepared user, or Rails answers empty response; the per-user keycloak-login flag and MFA can also block it. Ask Niklaus Buskirk for provisioning.
  2. Check the router is up.
    Expect HTTP 200 with no token.
  3. Check auth is enforced. Make the same call with { currentUser { id } } and no token. Expect HTTP 401 with {"errors":[{"message":"unauthorized"}]}.
  4. Call with the token. Add -H "authorization: Bearer $TOKEN" to the currentUser call. Expect HTTP 200 with your user. If you get data: null with Failed to fetch from Subgraph 'prepared911', Rails refused the token.
  5. Smoke-test a subscription. From an AxonMundi checkout, run its scripts/smoke-subscription.mjs:
    Expect a userNotification event within a few seconds and exit code 0.
    Known issue: the first subscription frame can error with Cannot return null for non-nullable field 'Subscription.userNotification'. This is likely on the Rails and AnyCable side, which Niklaus Buskirk is debugging. Real events still arrive after it.
  6. Try it from the responder. Local only, commit nothing.
    • In apps/responder/public/config/appConfig.json, set:
      AUTH_HOST_URL is the local apps/auth host that the next steps run. Instead of editing that file, you can put VITE_GRAPHQL_ROUTER_URL=<the router URL, $H> in apps/responder/.env.local; appConfig.json still wins when it sets a URL.
    • In apps/auth/.env, uncomment the KEYCLOAK_ISSUER, KEYCLOAK_CLIENT_ID and KEYCLOAK_SCOPE lines from .env.example. Without them the local sign-in offers only Okta.
    • Run apps/auth, then pnpm dev:responder, and sign in with Keycloak.
    • Also run pnpm --filter core dev (port 5109) alongside the shell. The prod core remote can lag trunk, and then the navbar crashes with reading 'stroke'.
    The navbar bell queries currentUser and subscribes to userNotification. Expect:
    • the bell shows the unread count;
    • the WebSocket (graphql-transport-ws) goes connection_init, connection_ack, then subscribe for OnUserNotification;
    • a live event arrives.
    CORS errors on mf-manifest.json are expected when the remotes are not served locally. The router calls had no CORS errors: the router allows any origin, and the responder sends no cookies.
  7. Shortcut for the console. pnpm dev:console:dev-router writes the router URL into the console's dev config (desktop/.axon911/console/appConfig.json) and starts the console with auth on. Set GRAPHQL_ROUTER_URL first to use another router. pnpm dev:console:desktop and node desktop/scripts/run-local.mjs also default the console's router URL to the dev router when none is set. Run apps/auth with the Keycloak lines from step 6 and pick Unified. There is no responder shortcut: the responder already signs in with Keycloak by default, so step 6 is all it needs.
Where the router URL comes from
The responder, console and switchboard read the router URL from these sources, first one set and acceptable wins:
  1. GRAPHQL_ROUTER_URL in the runtime config, /config/appConfig.json.
  2. VITE_GRAPHQL_ROUTER_URL, set when the shell is built.
Runtime config wins, so ops can repoint a deployed shell by serving a different appConfig.json, with no rebuild. The committed appConfig.json files are {}, so a deployment gets its URL from VITE_GRAPHQL_ROUTER_URL. Without either, the responder and console have no router client and switchboard uses its offline client.
  • The build-time value is public. Vite inlines every VITE_ variable into the bundle, so it is visible to anyone who loads the shell. Put only the router's public URL in it, never a token, key, or a URL with credentials.
  • A URL must be absolute https:, or http: for localhost, with no username or password. Anything else is ignored with one [graphql-router] ignoring ... warning in the browser console, which names the variable and not its value.
  • A build-time value reaches a deployment only after a new build. In Vercel, set it per environment on the responder, console and switchboard projects, then redeploy; the steps are in DEPLOY-VERCEL.mdopens in a new tab.
Do not paste the token into tickets, PRs, or Studio Playground sessions.
Previous
AxonMundi / Real-time data and WebSockets
Next
Testing strategy / Testing Principles
On this page
Where the router URL comes from