Aakash Connect Request new account frontend to backend

[aakashg00]

Closes #77
Connected request new account frontend and view/accept/decline requests frontend to their SDK methods by updating accountRequests.ts to use the SDK methods rather than placeholders, and updating the frontend to properly use the functions in accountRequests.ts, so requesting new accounts and accepting/declining requests works end to end.

Depends on GTBitsOfGood/juno-sdk#73 and GTBitsOfGood/juno#245 being merged first.

Video Demo of both accepting and declining new account requests:

Screen.Recording.2026-03-09.at.2.44.12.AM.mov

[netlify]

❌ Deploy Preview for juno-dashboard failed. Why did it fail? →

Name	Link
🔨 Latest commit	3718448
🔍 Latest deploy log	https://app.netlify.com/projects/juno-dashboard/deploys/69ae7d05fe45bf0008a19044

[greptile-apps]

Greptile Summary

This PR connects the account request frontend to the Juno SDK backend by replacing placeholder implementations in src/lib/accountRequests.ts with real SDK calls, and updating the request-account page and PendingAccountRequests component to use proper React Query mutations/queries with toast-based error handling.

Key changes:

• accountRequests.ts: All four functions (requestNewAccount, getAccountRequests, deleteAccountRequest, acceptAccountRequest) now call actual SDK methods with proper auth/admin guards and structured error handling.
• request-account/page.tsx: Replaced manual handleSubmit + useState loading/error pattern with useMutation, and errors are surfaced via sonner toast.
• PendingAccountRequests.tsx: Renamed declineAccountRequest → deleteAccountRequest, added useMemo sorting by createdAt, added cache invalidation for the projects query on accept, and added an error UI state for failed fetches.
• (auth)/layout.tsx: Wrapped with ReactQueryProvider to support the mutation hook in the request-account page.

Areas needing improvement:

• Four console.error calls were introduced in accountRequests.ts (lines 55, 100, 135, 184) and should be removed per the project checklist.
• The useEffect error toast in PendingAccountRequests fires every time data changes, meaning the error toast can repeat after cache invalidations triggered by accept/decline mutations.

PR score: 79/100 — The core integration is solid and well-structured. The two points above (debug logs and toast deduplication) are the main items to address before merging.

Confidence Score: 3/5

• Mostly safe to merge; two issues (console.error calls and repeated error toasts) should be addressed first.
• The SDK integration and auth guards are correct. The two flagged issues are non-breaking but affect code quality (debug logging in production) and UX (duplicate error toasts after mutations).
• src/lib/accountRequests.ts (console.error calls) and src/components/admin/PendingAccountRequests.tsx (useEffect toast deduplication)

Important Files Changed

Filename	Overview
src/lib/accountRequests.ts	Replaces placeholder implementations with real SDK calls for requestNewAccount, getAccountRequests, deleteAccountRequest, and acceptAccountRequest. Auth and admin guards are correctly applied. Four console.error calls should be removed per project checklist.
src/components/admin/PendingAccountRequests.tsx	Good addition of useMemo for sorted requests and query cache invalidation for projects. However, the useEffect-based toast pattern will re-fire error toasts on every query invalidation when the fetch is still failing, leading to duplicate notifications.
src/app/(auth)/request-account/page.tsx	Clean migration from manual form handling with placeholder TODO to useMutation. Error handling is correctly moved to toast notifications. Loading state uses isPending correctly.
src/app/(auth)/layout.tsx	ReactQueryProvider added to the auth layout to support useMutation in the request-account page — a necessary and correct addition.

Sequence Diagram

sequenceDiagram
    participant U as User (Browser)
    participant RQ as RequestAccountPage
    participant PA as PendingAccountRequests
    participant SA as Server Actions (accountRequests.ts)
    participant SDK as Juno SDK

    U->>RQ: Fill & submit form
    RQ->>SA: requestNewAccount(data)
    SA->>SDK: juno.auth.requestNewAccount(data)
    SDK-->>SA: success / error
    SA-->>RQ: { success, error? }
    RQ-->>U: Show success screen or toast error

    U->>PA: Admin views pending requests
    PA->>SA: getAccountRequests()
    SA->>SDK: juno.auth.getAllAccountRequests({ credentials })
    SDK-->>SA: { requests[] }
    SA-->>PA: { success, requests }
    PA-->>U: Render sorted request list

    U->>PA: Click Accept
    PA->>SA: acceptAccountRequest(request)
    SA->>SDK: juno.auth.acceptAccountRequest({ id, credentials })
    SDK-->>SA: { user, project? }
    SA-->>PA: { success, user, project? }
    PA->>PA: invalidate accountRequests, users, projects queries
    PA-->>U: Toast success / error

    U->>PA: Click Decline
    PA->>SA: deleteAccountRequest(id)
    SA->>SDK: juno.auth.deleteAccountRequest({ id, credentials })
    SDK-->>SA: success / error
    SA-->>PA: { success, error? }
    PA->>PA: invalidate accountRequests query
    PA-->>U: Toast success / error

Loading

_{Last reviewed commit: 53897ce}

[greptile-apps]

console.error calls should be removed

The PR checklist requires "No console.logs or commented out code." This PR introduces four console.error calls across the server action functions (lines 55, 100, 135, and 184). These should be removed before merging.

This same pattern also appears at:

• src/lib/accountRequests.ts:100 (getAccountRequests)
• src/lib/accountRequests.ts:135 (deleteAccountRequest)
• src/lib/accountRequests.ts:184 (acceptAccountRequest)

Suggested change

	console.error("Error requesting new account:", error.body);
	} catch (error) {
	return {

[greptile-apps]

Error toast will re-fire on every query invalidation

The useEffect depends on [data, error, isError]. When a user successfully accepts or declines a request, queryClient.invalidateQueries is called, which triggers a refetch of getAccountRequests. If the refetch returns the same { success: false, error: "..." } result, data will be a new object reference, causing this effect to run again and display a duplicate toast.

A more reliable pattern would be to use the onError / onSettled callbacks directly in the useQuery options, or guard with a useRef to track whether the toast has already been shown for a given error:

const hasShownErrorToast = useRef(false);

useEffect(() => {
  if (isError && !hasShownErrorToast.current) {
    hasShownErrorToast.current = true;
    toast.error("Error", {
      description: `Failed to fetch account requests: ${JSON.stringify(error)}`,
    });
    return;
  }
  if (data && !data.success && data.error && !hasShownErrorToast.current) {
    hasShownErrorToast.current = true;
    toast.error("Failed to Fetch Account Requests", { description: data.error });
  }
}, [data, error, isError]);