shad/canvas-frontend

Fork 0

Files

T

canvas-bot 14ae238cbb

build-and-publish / test (pull_request) Has been cancelled

Details

build-and-publish / image (pull_request) Has been cancelled

Details

qa(evidence): live production verification report

Captured against https://canvas.flow-master.ai with browser-style
probes + Playwright dogfood + raw fetches:

- Every /api/* through canvas's nginx returns 502 (proxy broken).
- demo.flow-master.ai upstream is alive (200/401 direct).
- Frontend calls auth routes that return 404 even direct on demo:
  /api/v1/auth/dev-login-config, /api/v1/auth/microsoft/login.
- User's 'GETs all 200' hypothesis was wrong — they're 502s.
- Zero EA2 traffic reaches the backend.

Repros in qa/evidence/_*.mjs. Screenshots + JSON dumps + full
report in qa/evidence/.

2026-06-15 01:21:19 +04:00

5.2 KiB

Raw Blame History

Canvas — production verification report

Date: 2026-06-14 Target: https://canvas.flow-master.ai Method: browser-style probes + Playwright dogfood, no kubectl access.

TL;DR

The live canvas frontend is healthy as a static SPA, but it is not connected to EA2. Every /api/* call through canvas's nginx proxy returns 502 Bad Gateway. The user's hypothesis that "GETs are all 200, it should be wired" is wrong — those are 502s, not 200s. Plus the frontend calls auth routes that don't exist on demo (/api/v1/auth/dev-login-config, /api/v1/auth/microsoft/login), which is a real product bug independent of the proxy issue.

Evidence

1. canvas /api/* → 502 (proxy broken)

GET  /api/v1/auth/dev-login-config              502 Bad Gateway
POST /api/v1/auth/dev-login                     502 Bad Gateway
GET  /api/v1/auth/me                            502 Bad Gateway
GET  /api/v1/auth/microsoft/login               502 Bad Gateway
GET  /api/ea2/work-items                        502 Bad Gateway
GET  /api/ea2/flow/processes?limit=10           502 Bad Gateway
GET  /api/ea2/process-definitions               502 Bad Gateway
GET  /api/runtime/transactions                  502 Bad Gateway

Body of every 502:

<html>
<head><title>502 Bad Gateway</title></head>
<body><center><h1>502 Bad Gateway</h1></center><hr><center>nginx</center></body>
</html>

Raw artifacts: qa/evidence/endpoint-probe.json, qa/evidence/canvas-proxy-ea2-error.html.

2. demo upstream is alive

GET  https://demo.flow-master.ai/                       200
GET  https://demo.flow-master.ai/api/ea2/work-items     401 (auth required, as expected)

So upstream is reachable from the public internet. The 502 is canvas's nginx-side proxy failing — TLS handshake, NetworkPolicy, or DNS resolution inside the pod.

3. Frontend calls routes that don't exist on demo

GET  https://demo.flow-master.ai/api/v1/auth/dev-login-config  → 404
GET  https://demo.flow-master.ai/api/v1/auth/microsoft/login   → 404
POST https://demo.flow-master.ai/api/v1/auth/dev-login         → unverified (proxy blocks the probe)

Even after the proxy is fixed, the Login scene will still fail because the auth endpoints aren't on demo. Either:

the frontend is targeting the wrong path prefix (should be /api/auth/...?), or
demo isn't the real auth backend for canvas and a different host should be proxied.

4. Playwright dogfood against live canvas

qa/full_dogfood.mjs first 5 checks:

PASS  auth_guard_unauthed_redirects_to_login
PASS  login_shows_three_personas — Mariana Cole · CEO | Aisha Khan · HR | Rohan Patel · IT
PASS  login_has_microsoft_sso_button
FAIL  ceo_persona_dev_login_lands_on_landing
FAIL  landing_exposes_all_hubs_and_extras
      missing: Procurement Hub, People Hub, IT Hub, Attendance Map,
               Command Assistant, Team Chat, What is FlowMaster?

The login screen renders correctly. Dev-login click never lands because the dev-login endpoint is 502.

5. Idle network during a 6-second landing visit

total /api/ calls: 1
by status: { "502": 1 }
endpoint: /api/v1/auth/microsoft  (SSO availability probe)

The "non-stop 200 GETs" the user saw in the console were either: (a) the probe + retry loop (1 call every few seconds, every one a 502, not 200), or (b) developer-tools showing the static-asset 200s and the user not differentiating from the failing /api calls. Either way, zero EA2 traffic is reaching the backend.

Root cause

Canvas's running nginx pod is at the build whose last-modified is Sun, 14 Jun 2026 17:02:30 GMT — pre-dating today's ops PRs. The image bumps in FM06/flowmaster-ops (#1173, #1174, #1175) did not roll the pod, because:

FM06/flowmaster-ops manifests/overlays/demo/mc-mission-control points at gitea.flow-master.ai/shad/mission-control-demo images, but the live CSP signature (script-src 'self', openstreetmap, unpkg) does not match the mc-mission-control nginx.conf. So the host canvas.flow-master.ai is not being served by mc-mission-control at all.
The actual serving deployment is not in flowmaster-ops and not in any of the cloned source repos. Either it's out-of-Gitops on the cluster or in a private repo not exposed.
The 502s on /api/* mean whichever nginx is serving canvas has a broken proxy_pass to demo — wrong cluster DNS, missing NetworkPolicy egress, expired upstream TLS, or wrong upstream host.

What needs cluster access to fix

Identify the deployment+pod actually serving canvas.flow-master.ai.
Verify its nginx.conf proxy_pass target and resolve why proxy_pass https://demo.flow-master.ai returns 502 from inside the pod.
Confirm NetworkPolicy allows egress to demo.flow-master.ai's IP from the pod's namespace.
Identify the correct auth API base path (/api/v1/auth/... does not exist on demo) and reconfigure the frontend or the upstream.

Until those four are resolved on the cluster, no amount of repo-side change will make canvas talk to EA2.

What did get fixed this session

shad/canvas-frontend README rewritten to match the shipped product (PR #1 merged).
Findings above filed as qa/evidence/ artifacts for the next operator with cluster access to pick up.

5.2 KiB Raw Blame History