fix(social): get_students 400s on nonexistent courses.user_id (#158)

[Jose-Gael-Cruz-Lopez]

After the #12 course_id migration, courses is a shared catalog with no user_id (enrollment lives in user_courses). get_students ran table("courses").select("user_id,course_name") and indexed courses_by_user[c["user_id"]]. PostgREST rejects selecting a nonexistent column with HTTP 400 (column courses.user_id does not exist), so the entire students / class-intel endpoint errored — and it's live (frontend/src/lib/api.tsgetStudents).

Fix — backend/routes/social.py

Join through user_courses and embed the course name:

enrollment_rows=table("user_courses").select("user_id,courses(course_name)")
forrowinenrollment_rows:
course=row.get("courses")
name=course.get("course_name") ifisinstance(course, dict) elseNoneifname:
courses_by_user[row["user_id"]].append(name)

Tests — backend/tests/test_social_get_students.py

• 200 with correct per-course grouping + mastery stats against the post-Schema Consolidation: Merge 1:1 Tables & Deduplicate Storage #12 shape.
• Students sorted by name.
• Regression guard: the endpoint reads user_courses and never selects user_id,course_name off courses.

Verification

• ruff check . clean; gated suite green (+3 new). The new tests fail against the pre-fix code (the catalog path yields no enrollments), confirming real coverage.

Closes#158.

[coderabbitai]

Warning

Review limit reached

@Jose-Gael-Cruz-Lopez, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c8aa414-96aa-4a5f-875b-2fb17bfe39d3

📥 Commits

Reviewing files that changed from the base of the PR and between 32409a8 and 3fc48bb.

📒 Files selected for processing (2)

• backend/routes/social.py
• backend/tests/test_social_get_students.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/social-get-students-courses-column

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	frontend	a9f1dd5	Jun 22 2026, 04:12 AM

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	3fc48bb	Commit Preview URL Branch Preview URL	Jun 24 2026, 02:42 PM

[AndresL230]

Superseded by the DB modular redesign (#279). social.get_students (#158) is rewired in the analytics slice to read enrollments → course_offerings → courses. Closing as obsolete. Reopen if not fully covered.

[AndresL230]

Reopening. Closed as superseded by #279, but this is an app-logic bugfix (social.get_students 400 on nonexistent course, #158), not a DB-structure change. Keeping it open to confirm the fix is actually covered by the redesign's analytics slice before closing again — if the rewired get_students already handles the missing-course case, we can re-close with a pointer to that commit; otherwise this fix still stands.

[AndresL230]

Closing this as superseded — the bug it targets is already fixed on main, and issue #158 is closed.

To be clear up front: the diagnosis in this PR was correct when it was written.courses.user_id genuinely didn't exist and the endpoint genuinely 400'd. What happened is that the schema moved underneath the branch while it was open.

What superseded it

PR #270 (db/analytics-code: social.py offering re-keying, epic slice PR4 of the #279 DB modular redesign — merged 2026-06-24, commit 736abc1) rewrote get_students on main to walk the enrollment chain:

enrollment_rows=table("enrollments").select("user_id,course_offerings(courses(course_name))")
name_map=get_display_names([u["id"] foruinusers])

That's the same fix this PR set out to make, arrived at independently, plus the services/profiles.py name resolution.

Why it can't be merged forward

This branch carries migrations up to 0018; main is at 0030. The fix here targets the 0018-era schema, so rebasing wouldn't rescue it — it would swap one nonexistent reference for another:

• user_courses no longer exists.0020_academics_split.sql:84 renamed it to enrollments. The new query would fail with a PostgREST "relation does not exist" (404) instead of the original 400 — still broken, different error.
• The courses(course_name) embed can't resolve.0020:85 renamed course_id → offering_id, FK'd to course_offerings(id) (0020:73-74). There's no direct enrollments → courses relationship; it has to go through course_offerings.
• users.name is gone.0024_identity_split.sql:25 dropped it; names moved to the encrypted user_profiles.name and resolve via get_display_names(). Reading it directly returns nothing.

GitHub already reports this as CONFLICTING on backend/routes/social.py, which is the two fixes colliding rather than ordinary drift.

The tests would need rewriting, not rebasing

tests/test_social_get_students.py pins the old schema — assert "user_courses" in recorder would fail against main's correct query. They also patch("routes.social.table") wholesale, so they'd pass against any table name and never reproduce the real PostgREST error.

Worth salvaging separately

One idea here is better than what's on main today: neither this PR nor main routes through services/academics.py, which the conventions call for — both hand-roll the embed. academics.py exposes user_offering_ids_for_course/offering_course_id but has no bulk "names for all enrollments" helper. Worth a follow-up ticket.

Also surfaced while reviewing, unrelated to this PR and present on main: get_students returns every user in the DB with their courses, mastery stats, and top concepts. It's authenticated but not scoped — the session user_id it fetches at social.py:426 is dead code. That looks intentional for a discovery surface, but it's a global cross-course disclosure worth an explicit decision.

Thanks @Jose-Gael-Cruz-Lopez — the analysis was right, the schema just moved. Closing.

[Jose-Gael-Cruz-Lopez]

After the #12 course_id migration, courses is a shared catalog with no user_id (enrollment lives in user_courses). get_students ran table("courses").select("user_id,course_name") and indexed courses_by_user[c["user_id"]]. PostgREST rejects selecting a nonexistent column with HTTP 400 (column courses.user_id does not exist), so the entire students / class-intel endpoint errored — and it's live (frontend/src/lib/api.tsgetStudents).

Fix — backend/routes/social.py

Join through user_courses and embed the course name:

enrollment_rows=table("user_courses").select("user_id,courses(course_name)")
forrowinenrollment_rows:
course=row.get("courses")
name=course.get("course_name") ifisinstance(course, dict) elseNoneifname:
courses_by_user[row["user_id"]].append(name)

Tests — backend/tests/test_social_get_students.py

• 200 with correct per-course grouping + mastery stats against the post-Schema Consolidation: Merge 1:1 Tables & Deduplicate Storage #12 shape.
• Students sorted by name.
• Regression guard: the endpoint reads user_courses and never selects user_id,course_name off courses.

Verification

• ruff check . clean; gated suite green (+3 new). The new tests fail against the pre-fix code (the catalog path yields no enrollments), confirming real coverage.

Closes#158.

[coderabbitai]

Warning

Review limit reached

@Jose-Gael-Cruz-Lopez, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c8aa414-96aa-4a5f-875b-2fb17bfe39d3

📥 Commits

Reviewing files that changed from the base of the PR and between 32409a8 and 3fc48bb.

📒 Files selected for processing (2)

• backend/routes/social.py
• backend/tests/test_social_get_students.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/social-get-students-courses-column

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	frontend	a9f1dd5	Jun 22 2026, 04:12 AM

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	3fc48bb	Commit Preview URL Branch Preview URL	Jun 24 2026, 02:42 PM

[AndresL230]

Superseded by the DB modular redesign (#279). social.get_students (#158) is rewired in the analytics slice to read enrollments → course_offerings → courses. Closing as obsolete. Reopen if not fully covered.

[AndresL230]

Reopening. Closed as superseded by #279, but this is an app-logic bugfix (social.get_students 400 on nonexistent course, #158), not a DB-structure change. Keeping it open to confirm the fix is actually covered by the redesign's analytics slice before closing again — if the rewired get_students already handles the missing-course case, we can re-close with a pointer to that commit; otherwise this fix still stands.

[AndresL230]

Closing this as superseded — the bug it targets is already fixed on main, and issue #158 is closed.

To be clear up front: the diagnosis in this PR was correct when it was written.courses.user_id genuinely didn't exist and the endpoint genuinely 400'd. What happened is that the schema moved underneath the branch while it was open.

What superseded it

PR #270 (db/analytics-code: social.py offering re-keying, epic slice PR4 of the #279 DB modular redesign — merged 2026-06-24, commit 736abc1) rewrote get_students on main to walk the enrollment chain:

enrollment_rows=table("enrollments").select("user_id,course_offerings(courses(course_name))")
name_map=get_display_names([u["id"] foruinusers])

That's the same fix this PR set out to make, arrived at independently, plus the services/profiles.py name resolution.

Why it can't be merged forward

This branch carries migrations up to 0018; main is at 0030. The fix here targets the 0018-era schema, so rebasing wouldn't rescue it — it would swap one nonexistent reference for another:

• user_courses no longer exists.0020_academics_split.sql:84 renamed it to enrollments. The new query would fail with a PostgREST "relation does not exist" (404) instead of the original 400 — still broken, different error.
• The courses(course_name) embed can't resolve.0020:85 renamed course_id → offering_id, FK'd to course_offerings(id) (0020:73-74). There's no direct enrollments → courses relationship; it has to go through course_offerings.
• users.name is gone.0024_identity_split.sql:25 dropped it; names moved to the encrypted user_profiles.name and resolve via get_display_names(). Reading it directly returns nothing.

GitHub already reports this as CONFLICTING on backend/routes/social.py, which is the two fixes colliding rather than ordinary drift.

The tests would need rewriting, not rebasing

tests/test_social_get_students.py pins the old schema — assert "user_courses" in recorder would fail against main's correct query. They also patch("routes.social.table") wholesale, so they'd pass against any table name and never reproduce the real PostgREST error.

Worth salvaging separately

One idea here is better than what's on main today: neither this PR nor main routes through services/academics.py, which the conventions call for — both hand-roll the embed. academics.py exposes user_offering_ids_for_course/offering_course_id but has no bulk "names for all enrollments" helper. Worth a follow-up ticket.

Also surfaced while reviewing, unrelated to this PR and present on main: get_students returns every user in the DB with their courses, mastery stats, and top concepts. It's authenticated but not scoped — the session user_id it fetches at social.py:426 is dead code. That looks intentional for a discovery surface, but it's a global cross-course disclosure worth an explicit decision.

Thanks @Jose-Gael-Cruz-Lopez — the analysis was right, the schema just moved. Closing.

[Jose-Gael-Cruz-Lopez]

After the #12 course_id migration, courses is a shared catalog with no user_id (enrollment lives in user_courses). get_students ran table("courses").select("user_id,course_name") and indexed courses_by_user[c["user_id"]]. PostgREST rejects selecting a nonexistent column with HTTP 400 (column courses.user_id does not exist), so the entire students / class-intel endpoint errored — and it's live (frontend/src/lib/api.tsgetStudents).

Fix — backend/routes/social.py

Join through user_courses and embed the course name:

enrollment_rows=table("user_courses").select("user_id,courses(course_name)")
forrowinenrollment_rows:
course=row.get("courses")
name=course.get("course_name") ifisinstance(course, dict) elseNoneifname:
courses_by_user[row["user_id"]].append(name)

Tests — backend/tests/test_social_get_students.py

• 200 with correct per-course grouping + mastery stats against the post-Schema Consolidation: Merge 1:1 Tables & Deduplicate Storage #12 shape.
• Students sorted by name.
• Regression guard: the endpoint reads user_courses and never selects user_id,course_name off courses.

Verification

• ruff check . clean; gated suite green (+3 new). The new tests fail against the pre-fix code (the catalog path yields no enrollments), confirming real coverage.

Closes#158.

[coderabbitai]

Warning

Review limit reached

@Jose-Gael-Cruz-Lopez, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c8aa414-96aa-4a5f-875b-2fb17bfe39d3

📥 Commits

Reviewing files that changed from the base of the PR and between 32409a8 and 3fc48bb.

📒 Files selected for processing (2)

• backend/routes/social.py
• backend/tests/test_social_get_students.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/social-get-students-courses-column

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	frontend	a9f1dd5	Jun 22 2026, 04:12 AM

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	3fc48bb	Commit Preview URL Branch Preview URL	Jun 24 2026, 02:42 PM

[AndresL230]

Superseded by the DB modular redesign (#279). social.get_students (#158) is rewired in the analytics slice to read enrollments → course_offerings → courses. Closing as obsolete. Reopen if not fully covered.

[AndresL230]

Reopening. Closed as superseded by #279, but this is an app-logic bugfix (social.get_students 400 on nonexistent course, #158), not a DB-structure change. Keeping it open to confirm the fix is actually covered by the redesign's analytics slice before closing again — if the rewired get_students already handles the missing-course case, we can re-close with a pointer to that commit; otherwise this fix still stands.

[AndresL230]

Closing this as superseded — the bug it targets is already fixed on main, and issue #158 is closed.

To be clear up front: the diagnosis in this PR was correct when it was written.courses.user_id genuinely didn't exist and the endpoint genuinely 400'd. What happened is that the schema moved underneath the branch while it was open.

What superseded it

PR #270 (db/analytics-code: social.py offering re-keying, epic slice PR4 of the #279 DB modular redesign — merged 2026-06-24, commit 736abc1) rewrote get_students on main to walk the enrollment chain:

enrollment_rows=table("enrollments").select("user_id,course_offerings(courses(course_name))")
name_map=get_display_names([u["id"] foruinusers])

That's the same fix this PR set out to make, arrived at independently, plus the services/profiles.py name resolution.

Why it can't be merged forward

This branch carries migrations up to 0018; main is at 0030. The fix here targets the 0018-era schema, so rebasing wouldn't rescue it — it would swap one nonexistent reference for another:

• user_courses no longer exists.0020_academics_split.sql:84 renamed it to enrollments. The new query would fail with a PostgREST "relation does not exist" (404) instead of the original 400 — still broken, different error.
• The courses(course_name) embed can't resolve.0020:85 renamed course_id → offering_id, FK'd to course_offerings(id) (0020:73-74). There's no direct enrollments → courses relationship; it has to go through course_offerings.
• users.name is gone.0024_identity_split.sql:25 dropped it; names moved to the encrypted user_profiles.name and resolve via get_display_names(). Reading it directly returns nothing.

GitHub already reports this as CONFLICTING on backend/routes/social.py, which is the two fixes colliding rather than ordinary drift.

The tests would need rewriting, not rebasing

tests/test_social_get_students.py pins the old schema — assert "user_courses" in recorder would fail against main's correct query. They also patch("routes.social.table") wholesale, so they'd pass against any table name and never reproduce the real PostgREST error.

Worth salvaging separately

One idea here is better than what's on main today: neither this PR nor main routes through services/academics.py, which the conventions call for — both hand-roll the embed. academics.py exposes user_offering_ids_for_course/offering_course_id but has no bulk "names for all enrollments" helper. Worth a follow-up ticket.

Also surfaced while reviewing, unrelated to this PR and present on main: get_students returns every user in the DB with their courses, mastery stats, and top concepts. It's authenticated but not scoped — the session user_id it fetches at social.py:426 is dead code. That looks intentional for a discovery surface, but it's a global cross-course disclosure worth an explicit decision.

Thanks @Jose-Gael-Cruz-Lopez — the analysis was right, the schema just moved. Closing.

[Jose-Gael-Cruz-Lopez]

After the #12 course_id migration, courses is a shared catalog with no user_id (enrollment lives in user_courses). get_students ran table("courses").select("user_id,course_name") and indexed courses_by_user[c["user_id"]]. PostgREST rejects selecting a nonexistent column with HTTP 400 (column courses.user_id does not exist), so the entire students / class-intel endpoint errored — and it's live (frontend/src/lib/api.tsgetStudents).

Fix — backend/routes/social.py

Join through user_courses and embed the course name:

enrollment_rows=table("user_courses").select("user_id,courses(course_name)")
forrowinenrollment_rows:
course=row.get("courses")
name=course.get("course_name") ifisinstance(course, dict) elseNoneifname:
courses_by_user[row["user_id"]].append(name)

Tests — backend/tests/test_social_get_students.py

• 200 with correct per-course grouping + mastery stats against the post-Schema Consolidation: Merge 1:1 Tables & Deduplicate Storage #12 shape.
• Students sorted by name.
• Regression guard: the endpoint reads user_courses and never selects user_id,course_name off courses.

Verification

• ruff check . clean; gated suite green (+3 new). The new tests fail against the pre-fix code (the catalog path yields no enrollments), confirming real coverage.

Closes#158.

[coderabbitai]

Warning

Review limit reached

@Jose-Gael-Cruz-Lopez, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c8aa414-96aa-4a5f-875b-2fb17bfe39d3

📥 Commits

Reviewing files that changed from the base of the PR and between 32409a8 and 3fc48bb.

📒 Files selected for processing (2)

• backend/routes/social.py
• backend/tests/test_social_get_students.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/social-get-students-courses-column

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	frontend	a9f1dd5	Jun 22 2026, 04:12 AM

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	3fc48bb	Commit Preview URL Branch Preview URL	Jun 24 2026, 02:42 PM

[AndresL230]

Superseded by the DB modular redesign (#279). social.get_students (#158) is rewired in the analytics slice to read enrollments → course_offerings → courses. Closing as obsolete. Reopen if not fully covered.

[AndresL230]

Reopening. Closed as superseded by #279, but this is an app-logic bugfix (social.get_students 400 on nonexistent course, #158), not a DB-structure change. Keeping it open to confirm the fix is actually covered by the redesign's analytics slice before closing again — if the rewired get_students already handles the missing-course case, we can re-close with a pointer to that commit; otherwise this fix still stands.

[AndresL230]

Closing this as superseded — the bug it targets is already fixed on main, and issue #158 is closed.

To be clear up front: the diagnosis in this PR was correct when it was written.courses.user_id genuinely didn't exist and the endpoint genuinely 400'd. What happened is that the schema moved underneath the branch while it was open.

What superseded it

PR #270 (db/analytics-code: social.py offering re-keying, epic slice PR4 of the #279 DB modular redesign — merged 2026-06-24, commit 736abc1) rewrote get_students on main to walk the enrollment chain:

enrollment_rows=table("enrollments").select("user_id,course_offerings(courses(course_name))")
name_map=get_display_names([u["id"] foruinusers])

That's the same fix this PR set out to make, arrived at independently, plus the services/profiles.py name resolution.

Why it can't be merged forward

This branch carries migrations up to 0018; main is at 0030. The fix here targets the 0018-era schema, so rebasing wouldn't rescue it — it would swap one nonexistent reference for another:

• user_courses no longer exists.0020_academics_split.sql:84 renamed it to enrollments. The new query would fail with a PostgREST "relation does not exist" (404) instead of the original 400 — still broken, different error.
• The courses(course_name) embed can't resolve.0020:85 renamed course_id → offering_id, FK'd to course_offerings(id) (0020:73-74). There's no direct enrollments → courses relationship; it has to go through course_offerings.
• users.name is gone.0024_identity_split.sql:25 dropped it; names moved to the encrypted user_profiles.name and resolve via get_display_names(). Reading it directly returns nothing.

GitHub already reports this as CONFLICTING on backend/routes/social.py, which is the two fixes colliding rather than ordinary drift.

The tests would need rewriting, not rebasing

tests/test_social_get_students.py pins the old schema — assert "user_courses" in recorder would fail against main's correct query. They also patch("routes.social.table") wholesale, so they'd pass against any table name and never reproduce the real PostgREST error.

Worth salvaging separately

One idea here is better than what's on main today: neither this PR nor main routes through services/academics.py, which the conventions call for — both hand-roll the embed. academics.py exposes user_offering_ids_for_course/offering_course_id but has no bulk "names for all enrollments" helper. Worth a follow-up ticket.

Also surfaced while reviewing, unrelated to this PR and present on main: get_students returns every user in the DB with their courses, mastery stats, and top concepts. It's authenticated but not scoped — the session user_id it fetches at social.py:426 is dead code. That looks intentional for a discovery surface, but it's a global cross-course disclosure worth an explicit decision.

Thanks @Jose-Gael-Cruz-Lopez — the analysis was right, the schema just moved. Closing.

[Jose-Gael-Cruz-Lopez]

After the #12 course_id migration, courses is a shared catalog with no user_id (enrollment lives in user_courses). get_students ran table("courses").select("user_id,course_name") and indexed courses_by_user[c["user_id"]]. PostgREST rejects selecting a nonexistent column with HTTP 400 (column courses.user_id does not exist), so the entire students / class-intel endpoint errored — and it's live (frontend/src/lib/api.tsgetStudents).

Fix — backend/routes/social.py

Join through user_courses and embed the course name:

enrollment_rows=table("user_courses").select("user_id,courses(course_name)")
forrowinenrollment_rows:
course=row.get("courses")
name=course.get("course_name") ifisinstance(course, dict) elseNoneifname:
courses_by_user[row["user_id"]].append(name)

Tests — backend/tests/test_social_get_students.py

• 200 with correct per-course grouping + mastery stats against the post-Schema Consolidation: Merge 1:1 Tables & Deduplicate Storage #12 shape.
• Students sorted by name.
• Regression guard: the endpoint reads user_courses and never selects user_id,course_name off courses.

Verification

• ruff check . clean; gated suite green (+3 new). The new tests fail against the pre-fix code (the catalog path yields no enrollments), confirming real coverage.

Closes#158.

[coderabbitai]

Warning

Review limit reached

@Jose-Gael-Cruz-Lopez, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c8aa414-96aa-4a5f-875b-2fb17bfe39d3

📥 Commits

Reviewing files that changed from the base of the PR and between 32409a8 and 3fc48bb.

📒 Files selected for processing (2)

• backend/routes/social.py
• backend/tests/test_social_get_students.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/social-get-students-courses-column

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	frontend	a9f1dd5	Jun 22 2026, 04:12 AM

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	3fc48bb	Commit Preview URL Branch Preview URL	Jun 24 2026, 02:42 PM

[AndresL230]

Superseded by the DB modular redesign (#279). social.get_students (#158) is rewired in the analytics slice to read enrollments → course_offerings → courses. Closing as obsolete. Reopen if not fully covered.

[AndresL230]

Reopening. Closed as superseded by #279, but this is an app-logic bugfix (social.get_students 400 on nonexistent course, #158), not a DB-structure change. Keeping it open to confirm the fix is actually covered by the redesign's analytics slice before closing again — if the rewired get_students already handles the missing-course case, we can re-close with a pointer to that commit; otherwise this fix still stands.

[AndresL230]

Closing this as superseded — the bug it targets is already fixed on main, and issue #158 is closed.

To be clear up front: the diagnosis in this PR was correct when it was written.courses.user_id genuinely didn't exist and the endpoint genuinely 400'd. What happened is that the schema moved underneath the branch while it was open.

What superseded it

PR #270 (db/analytics-code: social.py offering re-keying, epic slice PR4 of the #279 DB modular redesign — merged 2026-06-24, commit 736abc1) rewrote get_students on main to walk the enrollment chain:

enrollment_rows=table("enrollments").select("user_id,course_offerings(courses(course_name))")
name_map=get_display_names([u["id"] foruinusers])

That's the same fix this PR set out to make, arrived at independently, plus the services/profiles.py name resolution.

Why it can't be merged forward

This branch carries migrations up to 0018; main is at 0030. The fix here targets the 0018-era schema, so rebasing wouldn't rescue it — it would swap one nonexistent reference for another:

• user_courses no longer exists.0020_academics_split.sql:84 renamed it to enrollments. The new query would fail with a PostgREST "relation does not exist" (404) instead of the original 400 — still broken, different error.
• The courses(course_name) embed can't resolve.0020:85 renamed course_id → offering_id, FK'd to course_offerings(id) (0020:73-74). There's no direct enrollments → courses relationship; it has to go through course_offerings.
• users.name is gone.0024_identity_split.sql:25 dropped it; names moved to the encrypted user_profiles.name and resolve via get_display_names(). Reading it directly returns nothing.

GitHub already reports this as CONFLICTING on backend/routes/social.py, which is the two fixes colliding rather than ordinary drift.

The tests would need rewriting, not rebasing

tests/test_social_get_students.py pins the old schema — assert "user_courses" in recorder would fail against main's correct query. They also patch("routes.social.table") wholesale, so they'd pass against any table name and never reproduce the real PostgREST error.

Worth salvaging separately

One idea here is better than what's on main today: neither this PR nor main routes through services/academics.py, which the conventions call for — both hand-roll the embed. academics.py exposes user_offering_ids_for_course/offering_course_id but has no bulk "names for all enrollments" helper. Worth a follow-up ticket.

Also surfaced while reviewing, unrelated to this PR and present on main: get_students returns every user in the DB with their courses, mastery stats, and top concepts. It's authenticated but not scoped — the session user_id it fetches at social.py:426 is dead code. That looks intentional for a discovery surface, but it's a global cross-course disclosure worth an explicit decision.

Thanks @Jose-Gael-Cruz-Lopez — the analysis was right, the schema just moved. Closing.

[Jose-Gael-Cruz-Lopez]

After the #12 course_id migration, courses is a shared catalog with no user_id (enrollment lives in user_courses). get_students ran table("courses").select("user_id,course_name") and indexed courses_by_user[c["user_id"]]. PostgREST rejects selecting a nonexistent column with HTTP 400 (column courses.user_id does not exist), so the entire students / class-intel endpoint errored — and it's live (frontend/src/lib/api.tsgetStudents).

Fix — backend/routes/social.py

Join through user_courses and embed the course name:

enrollment_rows=table("user_courses").select("user_id,courses(course_name)")
forrowinenrollment_rows:
course=row.get("courses")
name=course.get("course_name") ifisinstance(course, dict) elseNoneifname:
courses_by_user[row["user_id"]].append(name)

Tests — backend/tests/test_social_get_students.py

• 200 with correct per-course grouping + mastery stats against the post-Schema Consolidation: Merge 1:1 Tables & Deduplicate Storage #12 shape.
• Students sorted by name.
• Regression guard: the endpoint reads user_courses and never selects user_id,course_name off courses.

Verification

• ruff check . clean; gated suite green (+3 new). The new tests fail against the pre-fix code (the catalog path yields no enrollments), confirming real coverage.

Closes#158.

[coderabbitai]

Warning

Review limit reached

@Jose-Gael-Cruz-Lopez, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c8aa414-96aa-4a5f-875b-2fb17bfe39d3

📥 Commits

Reviewing files that changed from the base of the PR and between 32409a8 and 3fc48bb.

📒 Files selected for processing (2)

• backend/routes/social.py
• backend/tests/test_social_get_students.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/social-get-students-courses-column

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	frontend	a9f1dd5	Jun 22 2026, 04:12 AM

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	3fc48bb	Commit Preview URL Branch Preview URL	Jun 24 2026, 02:42 PM

[AndresL230]

Superseded by the DB modular redesign (#279). social.get_students (#158) is rewired in the analytics slice to read enrollments → course_offerings → courses. Closing as obsolete. Reopen if not fully covered.

[AndresL230]

Reopening. Closed as superseded by #279, but this is an app-logic bugfix (social.get_students 400 on nonexistent course, #158), not a DB-structure change. Keeping it open to confirm the fix is actually covered by the redesign's analytics slice before closing again — if the rewired get_students already handles the missing-course case, we can re-close with a pointer to that commit; otherwise this fix still stands.

[AndresL230]

Closing this as superseded — the bug it targets is already fixed on main, and issue #158 is closed.

To be clear up front: the diagnosis in this PR was correct when it was written.courses.user_id genuinely didn't exist and the endpoint genuinely 400'd. What happened is that the schema moved underneath the branch while it was open.

What superseded it

PR #270 (db/analytics-code: social.py offering re-keying, epic slice PR4 of the #279 DB modular redesign — merged 2026-06-24, commit 736abc1) rewrote get_students on main to walk the enrollment chain:

enrollment_rows=table("enrollments").select("user_id,course_offerings(courses(course_name))")
name_map=get_display_names([u["id"] foruinusers])

That's the same fix this PR set out to make, arrived at independently, plus the services/profiles.py name resolution.

Why it can't be merged forward

This branch carries migrations up to 0018; main is at 0030. The fix here targets the 0018-era schema, so rebasing wouldn't rescue it — it would swap one nonexistent reference for another:

• user_courses no longer exists.0020_academics_split.sql:84 renamed it to enrollments. The new query would fail with a PostgREST "relation does not exist" (404) instead of the original 400 — still broken, different error.
• The courses(course_name) embed can't resolve.0020:85 renamed course_id → offering_id, FK'd to course_offerings(id) (0020:73-74). There's no direct enrollments → courses relationship; it has to go through course_offerings.
• users.name is gone.0024_identity_split.sql:25 dropped it; names moved to the encrypted user_profiles.name and resolve via get_display_names(). Reading it directly returns nothing.

GitHub already reports this as CONFLICTING on backend/routes/social.py, which is the two fixes colliding rather than ordinary drift.

The tests would need rewriting, not rebasing

tests/test_social_get_students.py pins the old schema — assert "user_courses" in recorder would fail against main's correct query. They also patch("routes.social.table") wholesale, so they'd pass against any table name and never reproduce the real PostgREST error.

Worth salvaging separately

One idea here is better than what's on main today: neither this PR nor main routes through services/academics.py, which the conventions call for — both hand-roll the embed. academics.py exposes user_offering_ids_for_course/offering_course_id but has no bulk "names for all enrollments" helper. Worth a follow-up ticket.

Also surfaced while reviewing, unrelated to this PR and present on main: get_students returns every user in the DB with their courses, mastery stats, and top concepts. It's authenticated but not scoped — the session user_id it fetches at social.py:426 is dead code. That looks intentional for a discovery surface, but it's a global cross-course disclosure worth an explicit decision.

Thanks @Jose-Gael-Cruz-Lopez — the analysis was right, the schema just moved. Closing.

[Jose-Gael-Cruz-Lopez]

After the #12 course_id migration, courses is a shared catalog with no user_id (enrollment lives in user_courses). get_students ran table("courses").select("user_id,course_name") and indexed courses_by_user[c["user_id"]]. PostgREST rejects selecting a nonexistent column with HTTP 400 (column courses.user_id does not exist), so the entire students / class-intel endpoint errored — and it's live (frontend/src/lib/api.tsgetStudents).

Fix — backend/routes/social.py

Join through user_courses and embed the course name:

enrollment_rows=table("user_courses").select("user_id,courses(course_name)")
forrowinenrollment_rows:
course=row.get("courses")
name=course.get("course_name") ifisinstance(course, dict) elseNoneifname:
courses_by_user[row["user_id"]].append(name)

Tests — backend/tests/test_social_get_students.py

• 200 with correct per-course grouping + mastery stats against the post-Schema Consolidation: Merge 1:1 Tables & Deduplicate Storage #12 shape.
• Students sorted by name.
• Regression guard: the endpoint reads user_courses and never selects user_id,course_name off courses.

Verification

• ruff check . clean; gated suite green (+3 new). The new tests fail against the pre-fix code (the catalog path yields no enrollments), confirming real coverage.

Closes#158.

[coderabbitai]

Warning

Review limit reached

@Jose-Gael-Cruz-Lopez, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c8aa414-96aa-4a5f-875b-2fb17bfe39d3

📥 Commits

Reviewing files that changed from the base of the PR and between 32409a8 and 3fc48bb.

📒 Files selected for processing (2)

• backend/routes/social.py
• backend/tests/test_social_get_students.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/social-get-students-courses-column

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	frontend	a9f1dd5	Jun 22 2026, 04:12 AM

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	3fc48bb	Commit Preview URL Branch Preview URL	Jun 24 2026, 02:42 PM

[AndresL230]

Superseded by the DB modular redesign (#279). social.get_students (#158) is rewired in the analytics slice to read enrollments → course_offerings → courses. Closing as obsolete. Reopen if not fully covered.

[AndresL230]

Reopening. Closed as superseded by #279, but this is an app-logic bugfix (social.get_students 400 on nonexistent course, #158), not a DB-structure change. Keeping it open to confirm the fix is actually covered by the redesign's analytics slice before closing again — if the rewired get_students already handles the missing-course case, we can re-close with a pointer to that commit; otherwise this fix still stands.

[AndresL230]

Closing this as superseded — the bug it targets is already fixed on main, and issue #158 is closed.

To be clear up front: the diagnosis in this PR was correct when it was written.courses.user_id genuinely didn't exist and the endpoint genuinely 400'd. What happened is that the schema moved underneath the branch while it was open.

What superseded it

PR #270 (db/analytics-code: social.py offering re-keying, epic slice PR4 of the #279 DB modular redesign — merged 2026-06-24, commit 736abc1) rewrote get_students on main to walk the enrollment chain:

enrollment_rows=table("enrollments").select("user_id,course_offerings(courses(course_name))")
name_map=get_display_names([u["id"] foruinusers])

That's the same fix this PR set out to make, arrived at independently, plus the services/profiles.py name resolution.

Why it can't be merged forward

This branch carries migrations up to 0018; main is at 0030. The fix here targets the 0018-era schema, so rebasing wouldn't rescue it — it would swap one nonexistent reference for another:

• user_courses no longer exists.0020_academics_split.sql:84 renamed it to enrollments. The new query would fail with a PostgREST "relation does not exist" (404) instead of the original 400 — still broken, different error.
• The courses(course_name) embed can't resolve.0020:85 renamed course_id → offering_id, FK'd to course_offerings(id) (0020:73-74). There's no direct enrollments → courses relationship; it has to go through course_offerings.
• users.name is gone.0024_identity_split.sql:25 dropped it; names moved to the encrypted user_profiles.name and resolve via get_display_names(). Reading it directly returns nothing.

GitHub already reports this as CONFLICTING on backend/routes/social.py, which is the two fixes colliding rather than ordinary drift.

The tests would need rewriting, not rebasing

tests/test_social_get_students.py pins the old schema — assert "user_courses" in recorder would fail against main's correct query. They also patch("routes.social.table") wholesale, so they'd pass against any table name and never reproduce the real PostgREST error.

Worth salvaging separately

One idea here is better than what's on main today: neither this PR nor main routes through services/academics.py, which the conventions call for — both hand-roll the embed. academics.py exposes user_offering_ids_for_course/offering_course_id but has no bulk "names for all enrollments" helper. Worth a follow-up ticket.

Also surfaced while reviewing, unrelated to this PR and present on main: get_students returns every user in the DB with their courses, mastery stats, and top concepts. It's authenticated but not scoped — the session user_id it fetches at social.py:426 is dead code. That looks intentional for a discovery surface, but it's a global cross-course disclosure worth an explicit decision.

Thanks @Jose-Gael-Cruz-Lopez — the analysis was right, the schema just moved. Closing.

[Jose-Gael-Cruz-Lopez]

After the #12 course_id migration, courses is a shared catalog with no user_id (enrollment lives in user_courses). get_students ran table("courses").select("user_id,course_name") and indexed courses_by_user[c["user_id"]]. PostgREST rejects selecting a nonexistent column with HTTP 400 (column courses.user_id does not exist), so the entire students / class-intel endpoint errored — and it's live (frontend/src/lib/api.tsgetStudents).

Fix — backend/routes/social.py

Join through user_courses and embed the course name:

enrollment_rows=table("user_courses").select("user_id,courses(course_name)")
forrowinenrollment_rows:
course=row.get("courses")
name=course.get("course_name") ifisinstance(course, dict) elseNoneifname:
courses_by_user[row["user_id"]].append(name)

Tests — backend/tests/test_social_get_students.py

• 200 with correct per-course grouping + mastery stats against the post-Schema Consolidation: Merge 1:1 Tables & Deduplicate Storage #12 shape.
• Students sorted by name.
• Regression guard: the endpoint reads user_courses and never selects user_id,course_name off courses.

Verification

• ruff check . clean; gated suite green (+3 new). The new tests fail against the pre-fix code (the catalog path yields no enrollments), confirming real coverage.

Closes#158.

[coderabbitai]

Warning

Review limit reached

@Jose-Gael-Cruz-Lopez, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 18 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5c8aa414-96aa-4a5f-875b-2fb17bfe39d3

📥 Commits

Reviewing files that changed from the base of the PR and between 32409a8 and 3fc48bb.

📒 Files selected for processing (2)

• backend/routes/social.py
• backend/tests/test_social_get_students.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/social-get-students-courses-column

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	frontend	a9f1dd5	Jun 22 2026, 04:12 AM

[cloudflare-workers-and-pages]

Deploying with Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	frontend-staging	3fc48bb	Commit Preview URL Branch Preview URL	Jun 24 2026, 02:42 PM

[AndresL230]

Superseded by the DB modular redesign (#279). social.get_students (#158) is rewired in the analytics slice to read enrollments → course_offerings → courses. Closing as obsolete. Reopen if not fully covered.

[AndresL230]

Reopening. Closed as superseded by #279, but this is an app-logic bugfix (social.get_students 400 on nonexistent course, #158), not a DB-structure change. Keeping it open to confirm the fix is actually covered by the redesign's analytics slice before closing again — if the rewired get_students already handles the missing-course case, we can re-close with a pointer to that commit; otherwise this fix still stands.

[AndresL230]

Closing this as superseded — the bug it targets is already fixed on main, and issue #158 is closed.

To be clear up front: the diagnosis in this PR was correct when it was written.courses.user_id genuinely didn't exist and the endpoint genuinely 400'd. What happened is that the schema moved underneath the branch while it was open.

What superseded it

PR #270 (db/analytics-code: social.py offering re-keying, epic slice PR4 of the #279 DB modular redesign — merged 2026-06-24, commit 736abc1) rewrote get_students on main to walk the enrollment chain:

enrollment_rows=table("enrollments").select("user_id,course_offerings(courses(course_name))")
name_map=get_display_names([u["id"] foruinusers])

That's the same fix this PR set out to make, arrived at independently, plus the services/profiles.py name resolution.

Why it can't be merged forward

This branch carries migrations up to 0018; main is at 0030. The fix here targets the 0018-era schema, so rebasing wouldn't rescue it — it would swap one nonexistent reference for another:

• user_courses no longer exists.0020_academics_split.sql:84 renamed it to enrollments. The new query would fail with a PostgREST "relation does not exist" (404) instead of the original 400 — still broken, different error.
• The courses(course_name) embed can't resolve.0020:85 renamed course_id → offering_id, FK'd to course_offerings(id) (0020:73-74). There's no direct enrollments → courses relationship; it has to go through course_offerings.
• users.name is gone.0024_identity_split.sql:25 dropped it; names moved to the encrypted user_profiles.name and resolve via get_display_names(). Reading it directly returns nothing.

GitHub already reports this as CONFLICTING on backend/routes/social.py, which is the two fixes colliding rather than ordinary drift.

The tests would need rewriting, not rebasing

tests/test_social_get_students.py pins the old schema — assert "user_courses" in recorder would fail against main's correct query. They also patch("routes.social.table") wholesale, so they'd pass against any table name and never reproduce the real PostgREST error.

Worth salvaging separately

One idea here is better than what's on main today: neither this PR nor main routes through services/academics.py, which the conventions call for — both hand-roll the embed. academics.py exposes user_offering_ids_for_course/offering_course_id but has no bulk "names for all enrollments" helper. Worth a follow-up ticket.

Also surfaced while reviewing, unrelated to this PR and present on main: get_students returns every user in the DB with their courses, mastery stats, and top concepts. It's authenticated but not scoped — the session user_id it fetches at social.py:426 is dead code. That looks intentional for a discovery surface, but it's a global cross-course disclosure worth an explicit decision.

Thanks @Jose-Gael-Cruz-Lopez — the analysis was right, the schema just moved. Closing.