fix: keep the /api prefix when proxying /api/logs/*

[a-effort]

Problem

GET /api/logs/activity fails through the BFF. The catch-all proxy strips its own /api before forwarding, on the assumption (stated in the file) that mcpgateway mounts every router at the root:

// Wildcard capture excludes the leading '/api/'; FastAPI routes are
// mounted at root, so reattach a single leading slash.

log_search declares prefix="/api/logs", so /api/logs/activity was forwarded to /logs/activity upstream and 404d.

Probed against a live gateway:

path	result
/api/logs/activity	401, route exists and needs auth
/logs/activity	404
/api/definitely-not-a-real-route	404, so the 401 above is meaningful

Why now

No caller had ever exercised an /api/logs/* route through the BFF. The other five log routes exist only as generated URL builders in contextForge.ts with no live callers, so the root-mount assumption was never tested. It surfaced the moment the Recent Activity feed asked for real data.

Fix

A toUpstreamPath() helper that keeps the prefix for logs/* and strips it for everything else, plus a correction to the now-false comment.

The exception is deliberately narrow. /api/logs is the only router in mcpgateway mounted under /api. The other 29 sit at the root or under root-relative prefixes (/v1/..., /admin/..., /observability/...) that already proxy correctly. That's recorded next to the constant so it doesn't get "simplified" back.

Tests

Two additions to server/test/proxy.test.ts: /api/logs/activity reaches upstream intact, and /api/logsearch still strips. The second guards the prefix match, since startsWith("logs") without the trailing slash would wrongly catch it.

BFF suite: 79 passed / 8 files. Server typecheck, eslint and prettier clean.

[marekdano]

Blocking

server/src/routes/proxy/catch-all.ts:92

rewriteUpstreamLocation() unconditionally prepends /api to a redirect Location path, but the PR's new toUpstreamPath() now forwards /api/logs/* requests upstream with /api already in the path (unlike every other route, which strips it).

Failure scenario: If mcpgateway issues a 307 for a logs request — which it will for any trailing-slash mismatch, since Starlette's default redirect_slashes=True is active and none of log_search's six routes (search, trace/{id}, security-events, audit-trails, activity, performance-metrics) are declared with a trailing slash — the rewritten Location becomes a doubled /api/api/logs/..., which 404s.

[vishu-bh]

solid implementation 🚀

[a-effort]

Good catch, @marekdano! Confirmed and fixed in 0fa007b. 🙌

rewriteUpstreamLocation() and toUpstreamPath() were inverses before this PR, which broke that on the logs branch. Reproduced: a 307 on a logs path came back to the browser as /api/api/logs/activity.

One correction on the trigger. Because none of the six routes declare a trailing slash, redirect_slashes fires only when a client requests one with a slash, not on the slash-free paths. Every current caller (src/api/activity.ts:39 and the five generated builders) emits slash-free URLs, so nothing was failing in practice. It was a latent trap rather than a live 404, and still worth closing since the asymmetry is invisible at the call site.

Fix is a toBrowserPath() that mirrors toUpstreamPath() off the same constant, so the two stay inverses if UPSTREAM_API_PREFIXES ever grows. Test added: upstream 307s /api/logs/activity/ to ${origin}/api/logs/activity, asserts the browser gets /api/logs/activity.