@CryogenicPlanetClaude finished @CryogenicPlanet's task in 2m 38s —— View job
PR Review
- Read docs reviewer guidelines
- Analyze PR changes
- Apply review checklist
- Post review feedback
Nice infrastructure addition overall. Found three issues worth fixing before merge.
Issue 1 — Static test always fails (bug)
docs/tests/static/agent-discovery.test.ts line 23:
await expect(access(filePath, constants.R_OK)).resolves.toBeNull();
fs.promises.access() resolves with undefined (void), not null. toBeNull() only matches null, so this assertion fails even when the file exists and is readable. The test would never pass on a correct deployment.
Fix:
// Option A — assert the right thing
await expect(access(filePath, constants.R_OK)).resolves.toBeUndefined();
// Option B — let rejection propagate naturally
await access(filePath, constants.R_OK); // throws if not readable
Issue 2 — Health endpoint checks production URLs in preview deployments
docs/app/api/health/route.ts checks:
API_V31_SPEC_URL=https://docs.composio.dev/openapi.json(hardcoded production)AUTHORIZATION_SERVER_METADATA_URL=https://backend.composio.dev/.well-known/oauth-authorization-server(always backend)
In the current Vercel preview deployment (docs-git-t3code-agent-discovery-metadata.preview.composio.dev), /api/health would always report pass/fail against production — it never checks whether the preview's own discovery surface is working. An agent reading the health endpoint during review will get a misleading result.
Fix: Derive the spec URL dynamically from the request origin so preview deployments check themselves:
export async function GET(request: NextRequest) {
const origin = new URL(request.url).origin;
const [specCheck, authCheck] = await Promise.all([
check(`${origin}/openapi.json`),
check(AUTHORIZATION_SERVER_METADATA_URL),
]);
// ...
}
Issue 3 — RFC 8414: issuer–metadata URL mismatch
docs/lib/agent-discovery.ts:
export const AUTH_ISSUER = 'https://backend.composio.dev/api/v3/auth/dash';
export const AUTHORIZATION_SERVER_METADATA_URL =
'https://backend.composio.dev/.well-known/oauth-authorization-server';
Per RFC 8414 §3, when the issuer contains a path, the discovery URL is formed by inserting /.well-known/oauth-authorization-server between the host and the path:
issuer: https://backend.composio.dev/api/v3/auth/dash
→ metadata: https://backend.composio.dev/.well-known/oauth-authorization-server/api/v3/auth/dash
The constant points to the root /.well-known/oauth-authorization-server instead. OAuth clients doing programmatic discovery from AUTH_ISSUER won't find the endpoint at the URL published in AUTHORIZATION_SERVER_METADATA_URL.
Separately: docs/app/.well-known/openid-configuration/route.ts serves metadata with issuer: 'https://backend.composio.dev/api/v3/auth/dash' from docs.composio.dev. OIDC clients verify that the issuer in the response matches the domain they fetched from — this check would fail since docs.composio.dev ≠ backend.composio.dev. If the intent is to mirror/proxy the backend's auth metadata, that should be documented explicitly; if the intent is docs-site-native OIDC, the issuer needs to be https://docs.composio.dev.
