[diegosouzapw]

Closes #3861

Problem

Adding a GitLab Duo connection (Providers → GitLab Duo → Add Connection) returned an opaque Internal server error before any redirect to GitLab. This is distinct from #3732 (a redirect-URI mismatch that only surfaces after the redirect): here buildAuthUrl throws when GITLAB_DUO_OAUTH_CLIENT_ID is unconfigured (GitLab Duo requires a self-registered OAuth app), and the authorize route swallowed the throw into a generic 500.

Fix (mirror the existing Qoder pattern)

• src/lib/oauth/providers/gitlab-duo.ts: buildAuthUrl now return null instead of throw when clientId is missing.
• src/app/api/oauth/[provider]/[action]/route.ts: a gitlab-duo guard (next to the existing qoder one) returns { supported: false, error } with actionable setup steps — register an app at https://gitlab.com/-/profile/applications, redirect URI http://localhost:20128/callback, scopes ai_features read_user, set GITLAB_DUO_OAUTH_CLIENT_ID.

The operator still needs to register the OAuth app to actually connect — but they now get a clear instruction instead of a 500.

Tests (TDD)

tests/unit/oauth-providers-config.test.ts: asserts buildAuthUrl returns null (not throws) with an empty clientId, and returns a valid authorize URL (client_id + PKCE challenge) when configured. The null assertion fails on the unfixed code (it threw). typecheck:core clean, lint 0 errors, file-size re-baselined (903→916, qoder-parallel guard, justified).

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request improves the error handling for GitLab Duo OAuth setup when the client ID is unconfigured. Instead of throwing an error and returning a generic 500 Internal Server Error, the system now returns a clear, actionable setup message. The changes include returning null from buildAuthUrl when clientId is missing, handling this case in the OAuth route, and adding a regression unit test. The reviewer suggested dynamically constructing the redirect URI in the error message using the request's origin instead of hardcoding http://localhost:20128/callback to support custom deployment setups.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Hardcoding the redirect URI to http://localhost:20128/callback in the error message can be misleading for operators running the application on a custom port, domain, or in a shared/VPS environment (as noted in the repository guide).

It is highly recommended to dynamically construct the redirect URI using the request's origin so that the instructions match the operator's actual deployment setup. Please ensure that the variable name request matches the parameter name of your GET route handler.

Suggested change

	if (provider === "gitlab-duo" && !authData.authUrl) {
	return NextResponse.json({
	...authData,
	supported: false,
	error:
	"GitLab Duo OAuth is not configured. Register an OAuth application at " +
	"https://gitlab.com/-/profile/applications with redirect URI " +
	"http://localhost:20128/callback and scopes \"ai_features read_user\", then set " +
	"GITLAB_DUO_OAUTH_CLIENT_ID (and optionally GITLAB_DUO_OAUTH_CLIENT_SECRET) and restart.",
	});
	if (provider === "gitlab-duo" && !authData.authUrl) {
	const origin = typeof request !== "undefined" ? new URL(request.url).origin : "http://localhost:20128";
	return NextResponse.json({
	...authData,
	supported: false,
	error:
	"GitLab Duo OAuth is not configured. Register an OAuth application at " +
	"https://gitlab.com/-/profile/applications with redirect URI " +
	origin + "/callback and scopes \"ai_features read_user\", then set " +
	"GITLAB_DUO_OAUTH_CLIENT_ID (and optionally GITLAB_DUO_OAUTH_CLIENT_SECRET) and restart.",
	});
	}