Skip to content

Fix/tutor profile registering #39

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AJ-505 wants to merge 9 commits into
base: main
Choose a base branch
from
Open

Fix/tutor profile registering #39

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
478ec0e
Feat: Add role badge to dashboard
AJ-505 Oct 25, 2025
0d5b6b4
Fix: role badge on dashboard
AJ-505 Oct 25, 2025
a266f44
Fix: Incorrect data persistence for onboarding across users
AJ-505 Oct 25, 2025
13cd5a7
Merge branch 'main' of https://github.com/Tobshub/tutorlink into feat…
AJ-505 Oct 25, 2025
c27d9ee
Merge branch 'main' of https://github.com/Tobshub/tutorlink into feat…
AJ-505 Oct 25, 2025
5ed80b5
Fix: Ensure tutors get registered after onboarding
AJ-505 Oct 25, 2025
0fc2990
Fix: Minor (and slightly major) issues
AJ-505 Oct 25, 2025
b575bf8
Schema changes - persist tutor preferred session types
AJ-505 Oct 25, 2025
1daa171
added migration
Tobshub Oct 25, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions prisma/migrations/20251025132207_tutorprofile_updates/migration.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
-- AlterTable
ALTER TABLE "TutorProfile" ADD COLUMN "preferredSessionTypes" TEXT[];
Comment on lines +1 to +2
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Oct 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify application code handles nullable preferredSessionTypes column.

The migration adds preferredSessionTypes as a nullable TEXT array with no DEFAULT value. Existing TutorProfile records will have NULL for this column upon migration completion. This can cause runtime errors if the application assumes the field always has a value.

Please verify that:

  1. The application code properly checks for NULL values before accessing or iterating over preferredSessionTypes
  2. The tutor profile creation/update logic correctly persists non-empty arrays to this column
  3. Consider whether a DEFAULT value (e.g., '{}' for an empty array) would be more appropriate to prevent NULL handling logic throughout the codebase

Run the following script to check how the field is referenced in application code:

Additionally, regarding the "P1017 Server has closed the connection" error mentioned in the PR comments: This appears to be a database connection issue rather than a SQL syntax error. Verify that your database server is running and the connection string is correct before re-running the migration.

🏁 Script executed:

#!/bin/bash
# Description: Verify application code handles preferredSessionTypes field and check for potential NULL issues

# Search for references to preferredSessionTypes in TypeScript/JavaScript files
rg -n "preferredSessionTypes" --type ts --type js -A 3 -B 1

# Search for array operations on the field to check if NULL is handled
rg -nP "preferredSessionTypes\s*\?" --type ts --type js

Length of output: 8178

🏁 Script executed:

#!/bin/bash
# Search for TutorProfile queries and direct database access to preferredSessionTypes
rg -n "TutorProfile" --type ts -A 5 -B 2 | grep -A 5 -B 2 "preferredSessionTypes"

# Look for schema.prisma to verify field definition
fd -e prisma -type f

# Search for any direct access patterns that might not handle NULL
rg -n "\\.preferredSessionTypes" --type ts -C 2

Length of output: 2920

🏁 Script executed:

#!/bin/bash
# Check the Prisma schema for the field definition
if [ -f schema.prisma ]; then
  cat schema.prisma | grep -A 5 -B 5 "preferredSessionTypes"
fi

# Also check if it might be in a different location
find . -name "*.prisma" -type f -exec grep -l "preferredSessionTypes" {} \;

Length of output: 22

🏁 Script executed:

#!/bin/bash
# Get the Prisma schema definition for TutorProfile and preferredSessionTypes
cat ./prisma/schema.prisma | grep -A 30 "model TutorProfile"

Length of output: 1067

Fix schema-migration mismatch: preferredSessionTypes must match nullability across both files.

The migration creates a nullable column (TEXT[] without NOT NULL), but the Prisma schema defines it as required (String[] without ?). This creates a data type mismatch: existing TutorProfile records will have NULL values that conflict with the non-nullable TypeScript type, causing runtime errors when code like Array.from(preferredSessionTypes) attempts to process NULL.

Choose one fix:

  1. Update migration to add DEFAULT '{}'::text[] and NOT NULL constraint to match schema requirement, OR
  2. Make the schema field optional: change preferredSessionTypes String[] to preferredSessionTypes String[]?

Option 1 is recommended to maintain the application's expectation of always having an array.

🤖 Prompt for AI Agents 
In prisma/migrations/20251025132207_tutorprofile_updates/migration.sql around
lines 1-2, the migration adds preferredSessionTypes as a nullable TEXT[] while
the Prisma schema declares it non-nullable (String[]), causing a nullability
mismatch; update the migration to make the column non-nullable with a safe
default by altering the statement to add DEFAULT '{}'::text[] and NOT NULL so
existing rows get an empty array and the DB matches the Prisma schema (i.e.,
ensure the migration sets DEFAULT '{}'::text[] and adds NOT NULL for
"preferredSessionTypes").

1 change: 1 addition & 0 deletions prisma/schema.prisma
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@ model TutorProfile {
teachingStyle String[]
tutorCredentials TutorCredentials[]
user User @relation(fields: [userId], references: [id])
preferredSessionTypes String[]
}

model TutorCredentials {
Expand Down
11 changes: 10 additions & 1 deletion src/app/dashboard/_components/sidebar.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ import Link from "next/link";
import { usePathname } from "next/navigation";
import { Home, Activity, BookOpen, MessageSquare, Phone, Settings } from "lucide-react";
import { useState } from "react";
import { api } from "@/trpc/react";

type Item = {
href: string;
Expand All @@ -22,9 +23,17 @@ const items: Item[] = [
export function Sidebar() {
const pathname = usePathname();
const [open, setOpen] = useState(false);
const { data: role } = api.signal.getViewerRole.useQuery();
const isTutor = role === "TUTOR";
Comment on lines +26 to +27
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Oct 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Handle loading state and consider extracting the role query logic.

The role query pattern is duplicated in both sidebar.tsx and settings/page.tsx. During initial load, role will be undefined, causing the badge to always show "👤 Student" until data arrives.

Solution 1: Add loading state handling

-    const { data: role } = api.signal.getViewerRole.useQuery();
-    const isTutor = role === "TUTOR";
+    const { data: role, isLoading } = api.signal.getViewerRole.useQuery();
+    const isTutor = role === "TUTOR";

Then render a loading indicator in the badge area while isLoading is true.

Solution 2 (recommended): Extract to a custom hook to reduce duplication

Create src/hooks/useViewerRole.ts:

import { api } from "@/trpc/react";

export function useViewerRole() {
    const { data: role, isLoading, error } = api.signal.getViewerRole.useQuery();
    const isTutor = role === "TUTOR";
    return { role, isTutor, isLoading, error };
}

Then use it in both components:

-    const { data: role } = api.signal.getViewerRole.useQuery();
-    const isTutor = role === "TUTOR";
+    const { isTutor, isLoading } = useViewerRole();
🤖 Prompt for AI Agents 
In src/app/dashboard/_components/sidebar.tsx around lines 26-27, the role query
result is used directly so during initial load role is undefined and the UI
shows "👤 Student" incorrectly; also the same query logic is duplicated
elsewhere. Fix by handling loading state: consume isLoading (and optionally
error) from api.signal.getViewerRole.useQuery and render a loading indicator in
the badge area while isLoading is true instead of defaulting to Student. To
remove duplication, extract the query into a reusable hook (e.g.,
src/hooks/useViewerRole.ts) that returns { role, isTutor, isLoading, error } and
import that hook in sidebar.tsx and settings/page.tsx.


const Nav = (
<nav className="rounded-2xl bg-white/90 p-3 shadow-sm backdrop-blur">
<div className="px-3 py-4 text-lg font-semibold text-neutral-900">TutorLink</div>
<div className="px-3 py-4">
<div className="text-lg font-semibold text-neutral-900">TutorLink</div>
<div className="mt-2 inline-block px-2.5 py-1 rounded-full text-xs font-semibold bg-indigo-100 text-indigo-900">
{isTutor ? "🎓 Tutor" : "👤 Student"}
</div>
</div>
<ul className="space-y-1">
{items.map((i) => {
const active = pathname === i.href;
Expand Down
35 changes: 35 additions & 0 deletions src/app/dashboard/settings/page.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,45 @@
"use client";

import { SignOutButton } from "@clerk/nextjs";
import Link from "next/link";
import { api } from "@/trpc/react";
import { Zap } from "lucide-react";

export default function SettingsPage() {
const { data: role, isLoading, isError } = api.signal.getViewerRole.useQuery();
const isTutor = !!role && role === "TUTOR";

return (
<div className="flex flex-col gap-6">
<h1 className="text-xl font-semibold text-neutral-900">Settings</h1>

{/* Loading state */}
{isLoading && (
<div className="pt-4 border-t border-neutral-200">
<div className="h-10 bg-neutral-200 rounded-lg animate-pulse"></div>
</div>
)}

{/* Error state */}
{isError && (
<div className="pt-4 border-t border-neutral-200">
<p className="text-sm text-red-600">Failed to load user role</p>
</div>
)}

{/* Tutor-specific section - only show when loaded and is tutor */}
{!isLoading && !isError && isTutor && (
<div className="pt-4 border-t border-neutral-200">
<h2 className="text-lg font-medium text-neutral-900 mb-4">Signals</h2>
<Link href="/dashboard/signal">
<button className="px-4 py-2 bg-indigo-600 text-white rounded-lg hover:bg-indigo-700 transition-colors flex items-center gap-2">
<Zap size={18} />
View Active Signals
</button>
</Link>
</div>
)}

<div className="pt-4 border-t border-neutral-200">
<h2 className="text-lg font-medium text-neutral-900 mb-4">Account</h2>
<SignOutButton redirectUrl="/">
Expand Down
7 changes: 7 additions & 0 deletions src/app/onboarding/page.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,11 +1,18 @@
"use client";
import Link from "next/link";
import { useEffect } from "react";
import { Button } from "@/components/ui/button";
import { useOnboardingStore } from "@/stores/onboarding";

export default function OnboardingIndex() {
const role = useOnboardingStore((s) => s.role);
const setRole = useOnboardingStore((s) => s.setRole);
const reset = useOnboardingStore((s) => s.reset);

// Clear any previous onboarding data when starting fresh
useEffect(() => {
reset();
}, [reset]);

return (
<div className="min-h-screen w-full bg-linear-to-b from-white via-blue-50 to-[#43A8FF]">
Expand Down
33 changes: 31 additions & 2 deletions src/app/onboarding/tutor/summary/page.tsx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,8 @@ import { useEffect } from "react";
import { useRouter } from "next/navigation";
import { Button } from "@/components/ui/button";
import { useOnboardingStore } from "@/stores/onboarding";
import { api } from "@/trpc/react";
import { toast } from "sonner";

export default function TutorSummary() {
const role = useOnboardingStore((s) => s.role);
Expand All @@ -13,13 +15,35 @@ export default function TutorSummary() {
const yearsOfExperience = useOnboardingStore((s) => s.yearsOfExperience);
const teachingStyle = Array.from(useOnboardingStore((s) => s.teachingStyle));
const preferredSessionTypes = Array.from(useOnboardingStore((s) => s.preferredSessionTypes));
const reset = useOnboardingStore((s) => s.reset);
const router = useRouter();

const { mutate: createProfile, isPending } = api.tutor.createProfile.useMutation({
onSuccess: () => {
toast.success("Profile created successfully!");
reset();
router.push("/dashboard");
},
onError: (error) => {
toast.error(error.message);
},
});

useEffect(() => {
if (!hydrated) return;
if (role !== "tutor") router.replace("/onboarding");
}, [hydrated, role, router]);

const handleFinish = () => {
createProfile({
subjectInterests,
teachingLevels,
yearsOfExperience: yearsOfExperience ?? 0,
teachingStyle,
preferredSessionTypes,
});
};
Comment on lines +37 to +45
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Oct 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify validation for required profile fields.

The function correctly passes onboarding data to the mutation. However, there's no client-side validation before submission. For instance, a tutor could submit with empty subjectInterests or teachingLevels arrays.

Confirm that server-side validation handles these cases appropriately. If so, consider adding client-side validation to improve UX by catching issues before the network request.

Run this script to check the server-side validation logic:

🏁 Script executed:

#!/bin/bash
# Description: Locate and examine the tutor.createProfile mutation handler to verify validation

# Find the createProfile mutation implementation
ast-grep --pattern 'createProfile: $_()'

# Also search for the procedure/mutation definition
rg -A 20 'createProfile.*=.*' --type ts

Length of output: 3160

I need to locate the server-side procedure implementation. Let me search for the tRPC router that defines the createProfile procedure:

Let me search for the tutor router file in the codebase:

Now let me search the codebase for the tutor router file:

🏁 Script executed:

#!/bin/bash
# Search for tutor router file and createProfile procedure

# Look for files containing tutor router
fd -e ts -e tsx | grep -E '(router|tutor)' | head -20

# Search for createProfile mutation definition
rg -A 30 'createProfile.*mutation\|createProfile.*:.*procedure' --type ts

Length of output: 741

Perfect! Found the tutor router. Let me examine it to find the createProfile procedure and its validation:

🏁 Script executed:

#!/bin/bash
# Examine the tutor router file for createProfile procedure

cat src/server/api/routers/tutor.ts

Length of output: 6297

Fix data loss and strengthen validation in createProfile procedure.

Server-side validation exists but has two critical issues:

  1. Data loss bug: The client sends preferredSessionTypes, but the server procedure (lines 51–56 in src/server/api/routers/tutor.ts) does not save it to the database. Add preferredSessionTypes: input.preferredSessionTypes to the tutorProfile.create() data object.

  2. Weak validation: Array fields allow empty arrays and yearsOfExperience has no bounds. Add .min(1) to array schemas and .min(0) to yearsOfExperience in the Zod input validation (lines 11–15).

🤖 Prompt for AI Agents 
In src/server/api/routers/tutor.ts around lines 51–56 and the Zod input schema
around lines 11–15: the server currently drops preferredSessionTypes and allows
empty arrays and unbounded yearsOfExperience. In the tutorProfile.create() data
object add preferredSessionTypes: input.preferredSessionTypes so the field is
persisted, and tighten validation by adding .min(1) to each array schema (so
arrays cannot be empty) and .min(0) to yearsOfExperience in the Zod input schema
to enforce a non-negative value.


return (
<div className="min-h-screen w-full bg-linear-to-b from-white via-blue-50 to-[#43A8FF]">
<div className="mx-auto max-w-7xl px-4 pt-4 sm:px-6 lg:px-8">
Expand Down Expand Up @@ -58,8 +82,13 @@ export default function TutorSummary() {
<Button asChild variant="brandOutline" className="rounded-full px-6">
<Link href="/onboarding/tutor/subjects">Back</Link>
</Button>
<Button variant="brand" className="rounded-full px-8 py-6 text-black" onClick={() => router.push("/dashboard")}>
Finish
<Button
variant="brand"
className="rounded-full px-8 py-6 text-black"
onClick={handleFinish}
disabled={isPending}
>
{isPending ? "Finishing..." : "Finish"}
</Button>
</div>
</main>
Expand Down
15 changes: 9 additions & 6 deletions src/server/api/routers/signal.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,16 @@ import { broadcastToTutors, notifyStudent } from "@/server/wsBridge";

export const signalRouter = createTRPCRouter({
// Returns the current viewer's role for conditional UI rendering
getViewerRole: protectedProcedure.query(async () => {
// Clerk manages auth, so default to STUDENT role
// Tutors will be explicitly set in DB when they complete tutor onboarding
return "STUDENT";
}),
getViewerRole: protectedProcedure.query(async ({ ctx }) => {
// Find user by Clerk ID and check if they have a tutor profile
const user = await ctx.db.user.findUnique({
where: { clerkUid: ctx.user.id },
select: { id: true, role: true },
});

createSignal: protectedProcedure
// If user exists in DB, use their role; otherwise default to STUDENT
return user?.role ?? "STUDENT";
}), createSignal: protectedProcedure
Comment on lines +10 to +19
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Oct 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Fix formatting on line 19 and verify user existence handling.

Line 19 has a formatting issue where the closing parenthesis, comma, and next procedure declaration are on the same line.

Apply this diff to fix the formatting:

         // If user exists in DB, use their role; otherwise default to STUDENT
         return user?.role ?? "STUDENT";
-    }), createSignal: protectedProcedure
+    }),
+
+    createSignal: protectedProcedure

Additional observation: The fallback to "STUDENT" when user is null handles the case where a Clerk user hasn't been synced to the database yet. Ensure your user sync logic (e.g., Clerk webhook) creates database records for all authenticated users, otherwise this fallback will mask missing user records.


---

🏁 Script executed:

```shell
#!/bin/bash
# Examine the signal.ts file to verify formatting and context
find . -name "signal.ts" -type f | head -20

Length of output: 34

🏁 Script executed:

#!/bin/bash
# Look at the full context around lines 10-19 and beyond
if [ -f "src/server/api/routers/signal.ts" ]; then
  echo "=== Lines 1-30 of signal.ts ===" && \
  sed -n '1,30p' src/server/api/routers/signal.ts && \
  echo "" && \
  echo "=== Lines 110-135 (for acceptSignal and TODO context) ===" && \
  sed -n '110,135p' src/server/api/routers/signal.ts
fi

Length of output: 2623

🏁 Script executed:

#!/bin/bash
# Search for TODO comments in signal.ts related to transactions/concurrency
if [ -f "src/server/api/routers/signal.ts" ]; then
  rg -n "TODO|FIXME|transact|concur" src/server/api/routers/signal.ts -A2 -B2
fi

Length of output: 291

🏁 Script executed:

#!/bin/bash
# Search for Clerk webhook handlers and user sync logic
find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" \) | xargs rg -l "clerk.*webhook|webhook.*user|user.*sync" 2>/dev/null | head -10

Length of output: 1275

🏁 Script executed:

#!/bin/bash
# Check for user creation/sync logic in server directory
rg -n "user.*create|onCreate.*user|webhook" src/server --type ts -A3 -B1 2>/dev/null | head -50

Length of output: 0

🏁 Script executed:

#!/bin/bash
# Verify the database schema for the user model
find . -type f \( -name "schema.prisma" -o -name "*schema*" \) | grep -E "(prisma|schema)" | head -5

Length of output: 263


---

🏁 Script executed:

```shell
#!/bin/bash
# Examine the Prisma schema to verify user model and clerkUid field
cat prisma/schema.prisma | grep -A 20 "model User"

Length of output: 764

🏁 Script executed:

#!/bin/bash
# Search for Clerk webhook handlers in API routes (next.js app structure)
find . -type f \( -name "*.ts" -o -name "*.tsx" \) -path "*/api/*" | xargs rg -l "clerk" 2>/dev/null | grep -v node_modules | head -10

Length of output: 162

🏁 Script executed:

#!/bin/bash
# Look for user creation in entire src directory with more context
rg -n "\.user\.create|\.user\.upsert" src/ --type ts -A 2 -B 2 2>/dev/null | head -40

Length of output: 789

🏁 Script executed:

#!/bin/bash
# Search for any webhook or sync logic files
find src -type f -name "*.ts" | xargs rg -l "webhook|sync|clerk" 2>/dev/null

Length of output: 292

🏁 Script executed:

#!/bin/bash
# Check for middleware that might handle Clerk authentication setup
find src -type f -name "*.ts" | xargs rg -l "middleware|auth|clerk" 2>/dev/null | head -10

Length of output: 220


---

🏁 Script executed:

```shell
#!/bin/bash
# Examine trpc.ts to understand ctx.user.id and how context is set up
cat src/server/api/trpc.ts | head -80

Length of output: 1996

🏁 Script executed:

#!/bin/bash
# Get full acceptSignal implementation context around line 111
sed -n '105,130p' src/server/api/routers/signal.ts

Length of output: 1202

🏁 Script executed:

#!/bin/bash
# Check if ctx.user is a Clerk user or application user
rg -n "ctx\.user" src/server/api/trpc.ts -B 3 -A 3 | head -50

Length of output: 350

Fix formatting on line 19 and correct the user lookup in acceptSignal.

Line 19 has a formatting issue where the closing parenthesis, comma, and next procedure are on the same line. Additionally, acceptSignal contains a critical bug: it queries the user by id: ctx.user.id, but ctx.user.id is the Clerk ID, not the Prisma user ID. The query must use clerkUid instead, matching the pattern in getViewerRole.

Apply these diffs:

Formatting fix (line 19):

         return user?.role ?? "STUDENT";
-    }), createSignal: protectedProcedure
+    }),
+
+    createSignal: protectedProcedure

Critical bug fix in acceptSignal (line 111):

             // Guard: Only tutors can accept signals - check DB role
             const me = await ctx.db.user.findUnique({
-                where: { id: ctx.user.id },
+                where: { clerkUid: ctx.user.id },
                 select: { id: true, role: true },
             });

Additional observation: Line 128 documents a known TODO about transactional handling and concurrency locks. This should be addressed separately to prevent race conditions on signal acceptance.

🤖 Prompt for AI Agents 
In src/server/api/routers/signal.ts around lines 10 to 19 and line 111, fix
formatting by moving the closing parenthesis/comma so the protectedProcedure
entries are on separate lines (ensure the getViewerRole procedure ends with its
own closing parenthesis and comma on line 19), and in acceptSignal change the
user lookup to query by clerkUid: ctx.user.id (matching getViewerRole) instead
of id: ctx.user.id to use the Clerk ID correctly; leave the TODO about
transactional/concurrency locking (line 128) to be handled separately.

.input(z.object({
message: z.string().min(1),
subject: z.string().min(1),
Expand Down
15 changes: 8 additions & 7 deletions src/server/api/routers/tutor.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,11 @@ import { TRPCError } from "@trpc/server";
export const tutorRouter = createTRPCRouter({
createProfile: protectedProcedure
.input(z.object({
subjectInterests: z.array(z.string()),
teachingLevels: z.array(z.string()),
yearsOfExperience: z.number(),
teachingStyle: z.array(z.string()),
preferredSessionTypes: z.array(z.string()),
subjectInterests: z.array(z.string()).min(1, "At least one subject is required"),
teachingLevels: z.array(z.string()).min(1, "At least one teaching level is required"),
yearsOfExperience: z.number().min(0, "Years of experience cannot be negative"),
teachingStyle: z.array(z.string()).min(1, "At least one teaching style is required"),
preferredSessionTypes: z.array(z.string()).min(1, "At least one session type is required"),
Copy link
Copy Markdown

@coderabbitai coderabbitai bot Oct 25, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Critical: preferredSessionTypes is validated but never saved.

Line 14 requires preferredSessionTypes with a minimum of 1 item, but the tutorProfile.create data object (lines 45-53) doesn't include it. This causes data loss—users provide this required field during registration, but it's never persisted to the database.

Apply this diff to save the field:

             const newProfile = await tx.tutorProfile.create({
                 data: {
                     userId: user.id,
                     subjectInterests: input.subjectInterests,
                     teachingLevels: input.teachingLevels,
                     yearsOfExperience: input.yearsOfExperience,
                     teachingStyle: input.teachingStyle,
+                    preferredSessionTypes: input.preferredSessionTypes,
                 },
             });

Consider also including preferredSessionTypes in the embedding text (lines 55-63) to improve tutor matching quality.

Also applies to: 45-53

🤖 Prompt for AI Agents 
In src/server/api/routers/tutor.ts around lines 14 and 45-63, the schema
requires preferredSessionTypes (line 14) but that field is not included in the
tutorProfile.create payload (lines 45-53) and therefore never persisted; update
the create data to include preferredSessionTypes so it is saved to the DB
(ensure the DB column/ORM accepts an array or appropriate type), and also append
preferredSessionTypes (e.g., joined as a comma-separated string) into the
embedding text construction (lines 55-63) so the value is included when
generating tutor embeddings for matching.

Copy link
Copy Markdown
Collaborator Author

@AJ-505 AJ-505 Oct 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think this is accurate @coderabbitai

Copy link
Copy Markdown

@coderabbitai coderabbitai bot Oct 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find and examine the Prisma schema to check TutorProfile model
fd -e prisma -x cat {}

Length of output: 2963

@AJ-505 You're absolutely right, and I apologize for the confusion.

After checking the Prisma schema, I can see that the TutorProfile model doesn't have a preferredSessionTypes field at all in the database schema. The model only includes:

  • subjectInterests
  • teachingLevels
  • yearsOfExperience
  • teachingStyle
  • embedding

The actual issue is a mismatch between the validation schema and the database schema:

  • Line 14 validates and requires preferredSessionTypes as input
  • But the database has no column to store it

This means either:

  1. The validation for preferredSessionTypes should be removed from the input schema (line 14), OR
  2. A database migration is needed to add the preferredSessionTypes column to the TutorProfile table

Which approach would you prefer? If preferredSessionTypes was intended to be stored, you'll need to add it to the Prisma schema and run a migration.

🧬 Code Graph Analysis Results

  • File: src/server/api/trpc.ts

    • Lines 78-78 
      export const createTRPCRouter = t.router;

  • File: src/server/api/trpc.ts

    • Lines 104-104 
      export const protectedProcedure = t.procedure.use(enforceUserIsAuthed);

  • File: src/server/api/trpc.ts

    • Lines 87-87 
      export const publicProcedure = t.procedure;

  • File: src/server/bedrock.ts

    • Lines 19-35 
      export const invokeModel = async (inputText: string) => {
  const command = new InvokeModelCommand({
    modelId,
    contentType: "application/json",
    accept: "*/*",
    body: JSON.stringify({
      inputText,
      dimensions: 512,
      normalize: true,
    }),
  });
  const response = await bedrockClient.send(command);
  const body = JSON.parse(new TextDecoder().decode(response.body)) as {
    embedding: number[];
  };
  return body;
};

}))
.mutation(async ({ ctx, input }) => {
const clerkUser = ctx.user;
Expand Down Expand Up @@ -49,6 +49,7 @@ export const tutorRouter = createTRPCRouter({
teachingLevels: input.teachingLevels,
yearsOfExperience: input.yearsOfExperience,
teachingStyle: input.teachingStyle,
preferredSessionTypes: input.preferredSessionTypes,
},
});

Expand All @@ -64,7 +65,7 @@ export const tutorRouter = createTRPCRouter({

const { embedding } = await invokeModel(embeddingText);

await ctx.db.tutorProfile.update({ where: { id: newProfile.id }, data: { embedding }});
await ctx.db.tutorProfile.update({ where: { id: newProfile.id }, data: { embedding } });

return newProfile;
});
Expand Down Expand Up @@ -121,7 +122,7 @@ ${updatedProfile.teachingLevels.map((l) => `- ${l}`).join("\n")}
Teaching Style:
${updatedProfile.teachingStyle.map((t) => `- ${t}`).join("\n")}
`);
await ctx.db.tutorProfile.update({ where: { id: updatedProfile.id}, data: { embedding}});
await ctx.db.tutorProfile.update({ where: { id: updatedProfile.id }, data: { embedding } });

return { success: true, message: "Tutor profile updated successfully", profile: updatedProfile };
}),
Expand Down