packages/stack-shared/src/interface/client-interface.ts (1)

739-739: Fix inconsistent return type in deleteOAuthProvider

The method signature indicates it returns Promise<void> but the implementation returns await response.json(). For a delete operation, it should either return void or the method signature should be updated to match the actual return type.

Apply this fix to make the implementation consistent with the signature:

-    return await response.json();
+    // Delete operations typically don't return data

Or update the method signature if a response is actually needed:

- ): Promise<void> {
+ ): Promise<any> {

packages/stack-shared/src/interface/server-interface.ts (1)

750-762: Fix return statement inconsistency!

The method signature indicates Promise<void> but line 761 returns await response.json(). For a void return type, the implementation should not return any value.

Apply this fix:

  async deleteServerOAuthProvider(
    userId: string,
    providerId: string,
  ): Promise<void> {
-   const response = await this.sendServerRequest(
+   await this.sendServerRequest(
      urlString`/oauth-providers/${userId}/${providerId}`,
      {
        method: "DELETE",
      },
      null,
    );
-   return await response.json();
  }

packages/template/src/lib/stack-app/apps/implementations/client-app-impl.ts (1)

828-838: Violation of API naming convention: Using camelCase parameters in API interfaces

According to the naming convention rule, parameters used in API communication should use snake_case. The parameters 'allowSignIn' and 'allowConnectedAccounts' should be 'allow_sign_in' and 'allow_connected_accounts' for consistency with HTTP API naming conventions.

packages/template/src/lib/stack-app/index.ts (1)

54-58: Minor nitpick: Unnecessary export reordering

The reordering of permission-related exports doesn't appear to serve a functional purpose and could make the git history less clear.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/users/[userId]/page-client.tsx (2)

1113-1113: Use template literal for compound key

For better readability and consistency with modern JavaScript practices.

-                <TableRow key={provider.id + '-' + provider.accountId}>
+                <TableRow key={`${provider.id}-${provider.accountId}`}>

---

1231-1232: Replace empty div spacer with proper flex gap

The empty div appears to be used as a spacer. Consider using the parent's flex gap or adding a specific spacing class for better maintainability.

         <ContactChannelsSection user={user} />
         <OAuthProvidersSection user={user} />
-        <div />
         <MetadataSection user={user} />

If additional spacing is needed between OAuthProvidersSection and MetadataSection, consider adjusting the parent's gap-6 class or adding margin to the MetadataSection component.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/users/[userId]/page-client.tsx (3)

951-955: Allow clearing the email on update (don’t silently restore the old value).

Current fallback prevents clearing. Pass undefined to keep, or empty string to clear, based on the form value.

-      result = await provider.update({
-        email: values.email?.trim() || provider.email,
+      const nextEmail = values.email === undefined ? undefined : values.email.trim();
+      const updateRes = await provider.update({
+        email: nextEmail,
         allowSignIn: values.allowSignIn,
         allowConnectedAccounts: values.allowConnectedAccounts,
       });

---

907-916: Use schema validation for accountId instead of manual early return.

Rely on yup and show a field error rather than silently returning.

-    accountId: yup.string()
-      .defined("Account ID is required")
+    accountId: yup.string()
+      .trim()
+      .min(1, "Account ID is required")
       .label("Account ID")
@@
-      // Create new provider
-      if (!values.accountId.trim()) return;
+      // Create new provider (schema ensures non-empty accountId)

---

1163-1168: Ask for confirmation before deleting an OAuth provider.

Avoid accidental destructive actions.

-                          onClick: async () => {
-                            await provider.delete();
-                          },
+                          onClick: async () => {
+                            if (confirm("Delete this OAuth provider? This action cannot be undone.")) {
+                              await provider.delete();
+                            }
+                          },

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

packages/stack-shared/src/interface/client-interface.ts (3)

1678-1691: Encode path segments using urlString to prevent malformed URLs

Safer and consistent with the rest of the file (see getItem). Also future-proofs against ids containing reserved chars.

-    const response = await this.sendClientRequest(
-      `/oauth-providers/${userId}/${providerId}`,
+    const response = await this.sendClientRequest(
+      urlString`/oauth-providers/${userId}/${providerId}`,

---

1693-1711: Encode path + strip undefined keys on PATCH body

• Use urlString for safe path construction.
• filterUndefined avoids sending undefined properties that may fail schema validation.

-    const response = await this.sendClientRequest(
-      `/oauth-providers/${userId}/${providerId}`,
+    const response = await this.sendClientRequest(
+      urlString`/oauth-providers/${userId}/${providerId}`,
       {
         method: "PATCH",
         headers: {
           "content-type": "application/json",
         },
-        body: JSON.stringify(data),
+        body: JSON.stringify(filterUndefined(data)),
       },

---

1713-1729: Type the list response for stronger guarantees

Casting to the List shape ensures .items exists and matches the CRUD contract.

-    const response = await this.sendClientRequest(
+    const response = await this.sendClientRequest(
       `/oauth-providers${queryParams.toString() ? `?${queryParams.toString()}` : ''}`,
       {
         method: "GET",
       },
       session,
     );
-    const result = await response.json();
+    const result = await response.json() as OAuthProviderCrud['Client']['List'];
     return result.items;

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

apps/e2e/tests/js/oauth-providers.test.ts (12)

123-126: Minor: simplify with resolves.

Keeps it compact and consistent with the rest of the file.

-    const provider = await currentUser.getOAuthProvider("non-existent-id");
-
-    expect(provider).toBeNull();
+    await expect(currentUser.getOAuthProvider("non-existent-id")).resolves.toBeNull();

---

139-142: Use an inline snapshot for empty list.

Improves readability and aligns with test guidelines.

-    expect(providers).toHaveLength(0);
+    expect(providers).toMatchInlineSnapshot(`[]`);

---

161-166: Prefer positive assertion over manual throw for Result ergonomics.

Assert success explicitly; removes the need for a manual throw and non-null assertion later.

-    if (createdProviderResult.status === "error") {
-      throw new Error("Failed to create OAuth provider");
-    }
-
-    const createdProvider = createdProviderResult.data!;
+    expect(createdProviderResult.status).toBe("success");
+    const createdProvider = createdProviderResult.data!;

Apply the same pattern to similar blocks below.

---

170-178: Re-assert provider_config_id after update to guard accidental mutation.

Confirms updates don’t touch immutable identity fields.

     await provider!.update({ allowSignIn: false, allowConnectedAccounts: false });
 
     const updatedProvider = await currentUser.getOAuthProvider(createdProvider.id);
+    expect(updatedProvider?.provider_config_id).toBe("spotify");
     expect(updatedProvider?.allowSignIn).toBe(false);
     expect(updatedProvider?.allowConnectedAccounts).toBe(false);

---

197-202: Repeat the Result handling refactor here.

-    if (createdProviderResult.status === "error") {
-      throw new Error("Failed to create OAuth provider");
-    }
-
-    const createdProvider = createdProviderResult.data!;
+    expect(createdProviderResult.status).toBe("success");
+    const createdProvider = createdProviderResult.data!;

---

214-216: Snapshot empty providers after delete for clarity.

-    const providers = await currentUser.listOAuthProviders();
-    expect(providers).toHaveLength(0);
+    const providers = await currentUser.listOAuthProviders();
+    expect(providers).toMatchInlineSnapshot(`[]`);

---

251-257: Snapshot the sorted provider types; also assert deterministic order in one go.

Inline snapshot documents expected ordering and avoids manual array construction.

-    const providerTypes = providers.map((p: any) => p.type).sort((a, b) => stringCompare(a, b));
-    expect(providerTypes).toEqual(["github", "spotify"]);
+    const providerTypes = providers.map((p: any) => p.type).sort((a, b) => stringCompare(a, b));
+    expect(providerTypes).toMatchInlineSnapshot(`
+      [
+        "github",
+        "spotify",
+      ]
+    `);

---

259-289: Also assert provider_config_id remains unchanged after email update.

Guards against regressions touching provider identity while updating mutable fields.

     const provider = await currentUser.getOAuthProvider(createdProvider.id);
+    expect(provider?.provider_config_id).toBe("spotify");
     expect(provider?.email).toBe("[email protected]");

---

276-281: Repeat the Result handling refactor here.

-    if (createdProviderResult.status === "error") {
-      throw new Error("Failed to create OAuth provider");
-    }
-
-    const createdProvider = createdProviderResult.data!;
+    expect(createdProviderResult.status).toBe("success");
+    const createdProvider = createdProviderResult.data!;

---

218-257: Add a quick assertion on provider_config_id for the enabled provider.

Complements the type ordering check with the new field.

     const enabledForSignIn = providers.filter((p: any) => p.allowSignIn);
     expect(enabledForSignIn).toHaveLength(1);
     expect(enabledForSignIn[0].type).toBe("spotify");
+    expect(enabledForSignIn[0].provider_config_id).toBe("spotify");

---

6-27: Optional: Extract a tiny helper to unwrap success Results and reduce repetition.

If you keep returning Result-like objects in tests, a helper keeps tests terse and consistent.

Add near the top inside the describe:

 describe("OAuth Providers Client Functions", () => {
+  function unwrapSuccess(result) {
+    expect(result.status).toBe("success");
+    return result.data;
+  }

Then replace patterns like:

const createdProvider = unwrapSuccess(createdProviderResult);

---

290-290: Consider adding a test for account-ID conflict errors.

PR notes improved handling for account-ID conflicts. A focused e2e test will prevent regressions.

Example to add after the last test:

it("should error on duplicate accountId for same provider_config_id", async ({ expect }) => {
  const apps = await createAppsWithOAuth();
  const user = await apps.serverApp.createUser({
    primaryEmail: "[email protected]",
    password: "password123",
    primaryEmailAuthEnabled: true,
  });

  const first = await apps.serverApp.createOAuthProvider({
    userId: user.id,
    providerConfigId: "spotify",
    accountId: "spotify_user_123",
    email: "[email protected]",
    allowSignIn: true,
    allowConnectedAccounts: true,
  });
  expect(first.status).toBe("success");

  const second = await apps.serverApp.createOAuthProvider({
    userId: user.id,
    providerConfigId: "spotify",
    accountId: "spotify_user_123", // duplicate
    email: "[email protected]",
    allowSignIn: true,
    allowConnectedAccounts: true,
  });

  expect(second.status).toBe("error");
  // Optionally assert specific error code/message if defined by API contract:
  // expect(second.error.code).toBe("oauth_provider_account_conflict");
});

I can wire this to whatever error code your API returns—tell me the canonical code/message and I’ll finalize it.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro