promote: test → main (GET /api/sessions/[sessionId])

[sweetmantech]

Summary

Promotes the GET endpoint into main:

• feat(sessions): port GET /api/sessions/[sessionId] from open-agents (Phase 2.4) #514 — feat(sessions): port GET /api/sessions/[sessionId] from open-agents — reads via selectSessions({id}), enforces ownership (403 cross-account / 404 missing / 401 unauth), returns the same Session shape POST returns

Test plan

• CI green on test (format / lint / test all SUCCESS)
• Smoke-tested live on PR feat(sessions): port GET /api/sessions/[sessionId] from open-agents (Phase 2.4) #514 preview (401 / 404 / 200) — see PR comment
• Field-by-field match against docs at developers.recoupable.com/api-reference/sessions/get

---

Summary by cubic

Promotes the GET session-by-id endpoint to main, adding /api/sessions/[sessionId] with auth and ownership checks. Returns the same camelCase session shape as POST to support open-agents cutover without frontend changes.

• New Features
  • Added route with OPTIONS preflight and cache controls (dynamic="force-dynamic", fetchCache="force-no-store", revalidate=0).
  • Implemented getSessionByIdHandler using validateAuthContext and selectSessions({ id }); returns 401/403/404 with { status: "error", error } and CORS headers; 200 returns { session }.
  • Added tests for 401, 404, 403, 200, and OPTIONS.

^{Written for commit b2dd017. Summary will update on new commits.}

Summary by CodeRabbit

Release Notes

• New Features
  • Added API endpoint to retrieve session details with secure authentication validation and proper error handling for unauthorized or missing sessions.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
api	Ready	Preview	May 5, 2026 0:01am

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR introduces a new API endpoint GET /api/sessions/[sessionId] with CORS support. The route handler extracts the session ID from URL parameters, delegates to a business logic handler that validates authentication, fetches the session from the database, enforces ownership checks, and returns the session or appropriate error responses.

Changes

Session Fetch Endpoint

Layer / File(s)	Summary
Authentication & Authorization lib/sessions/getSessionByIdHandler.ts	Validates request authentication context and enforces account ownership by comparing session account_id with authenticated accountId.
Data Access lib/sessions/getSessionByIdHandler.ts	Queries session by sessionId using selectSessions() and handles missing records with appropriate error responses.
Response Serialization lib/sessions/getSessionByIdHandler.ts	Shapes database rows into client response format via toSessionResponse() and includes CORS headers in all responses.
Route Wiring app/api/sessions/[sessionId]/route.ts	Exports GET and OPTIONS handlers; extracts async sessionId param and delegates to handler; configures route as force-dynamic with no caching.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Route Handler
    participant Auth Validator
    participant Database
    participant Response Formatter

    Client->>Route Handler: GET /api/sessions/{sessionId}
    Route Handler->>Auth Validator: validateAuthContext(request)
    alt Auth Invalid
        Auth Validator-->>Route Handler: Error Response
    else Auth Valid
        Route Handler->>Database: selectSessions({ id: sessionId })
        alt Session Not Found
            Database-->>Route Handler: Empty Result
            Route Handler-->>Client: 404 { error: "Session not found" }
        else Session Found
            alt Account Mismatch
                Route Handler-->>Client: 403 { error: "Forbidden" }
            else Account Match
                Database-->>Response Formatter: Session Row
                Response Formatter-->>Route Handler: Serialized Session
                Route Handler-->>Client: 200 { session: {...} }
            end
        end
    end

Loading

Estimated Code Review Effort

🎯 2 (Simple) | ⏱️ ~12 minutes

The changes follow a straightforward, familiar authentication-and-database-lookup pattern with clear error handling. Two cohesive files, ~93 lines of code, standard Next.js 13+ App Router conventions, and no complex logic branches. Reviewers should verify authentication enforcement, database query correctness, and CORS header consistency.

Possibly Related PRs

• recoupable/api#514: Introduces the same GET /api/sessions/[sessionId] endpoint with identical handler logic, authentication checks, and response serialization.

Poem

Sessions unlocked with a single ID, 🔑
Auth guards the gate with watchful eye,
Database whispers secrets true,
CORS headers sail the web anew! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Solid & Clean Code	⚠️ Warning	Missing Zod parameter validation for sessionId and unhandled data-layer errors. Violates Clean Code guidelines for API validation and error handling.	Add Zod sessionIdParamsSchema validation in route. Add try-catch around selectSessions() to return 500 with consistent error envelope on data failures.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch test

---

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 and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

lib/sessions/getSessionByIdHandler.ts (1)

21-51: ⚡ Quick win

Split the handler into small helpers to meet function-size constraints.

This function exceeds the repository’s max-length guideline; extracting response builders/guards will keep it easier to evolve.

As per coding guidelines, “Flag functions longer than 20 lines” and “Keep functions small and focused.”

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/sessions/getSessionByIdHandler.ts` around lines 21 - 51, Split
getSessionByIdHandler into small helpers: create getSessionOr404(sessionId) that
calls selectSessions and returns the row or returns the 404 NextResponse (use
getCorsHeaders), create assertSessionOwnership(row, auth) that returns a 403
NextResponse when row.account_id !== auth.accountId or null on success, and
create okSessionResponse(row) that returns the 200 NextResponse with
toSessionResponse(row) and CORS headers; then refactor getSessionByIdHandler to
call validateAuthContext(request), then getSessionOr404(sessionId), then
assertSessionOwnership(row, auth), and finally return okSessionResponse(row),
keeping all response construction in the new helpers and leaving
validateAuthContext, selectSessions, toSessionResponse, and getCorsHeaders usage
intact.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@app/api/sessions/`[sessionId]/route.ts:
- Around line 32-37: Add a Zod-based parameter validator for sessionId and call
it from the GET route before invoking getSessionByIdHandler: create a function
(e.g., validateSessionParams) modeled after validateAccountParams /
validateAddArtistBody that accepts the raw params object, defines a Zod schema
for { sessionId: string } (with any required format checks), returns the parsed
value on success or a NextResponse with a 400 error on failure, then update the
GET handler to await validateSessionParams(options.params) and only call
getSessionByIdHandler(request, sessionId) when validation passes.

In `@lib/sessions/getSessionByIdHandler.ts`:
- Around line 30-50: selectSessions can throw and currently bubbles out,
breaking the endpoint's JSON+CORS contract; wrap the call to selectSessions({
id: sessionId }) in a try/catch inside getSessionByIdHandler (or the handler
function in this file), and on any caught error return a NextResponse.json({
status: "error", error: "Internal server error" }, { status: 500, headers:
getCorsHeaders() }); optionally log the caught error before returning; keep the
rest of the control flow (not-found, forbidden, success using
toSessionResponse(row)) unchanged.

---

Nitpick comments:
In `@lib/sessions/getSessionByIdHandler.ts`:
- Around line 21-51: Split getSessionByIdHandler into small helpers: create
getSessionOr404(sessionId) that calls selectSessions and returns the row or
returns the 404 NextResponse (use getCorsHeaders), create
assertSessionOwnership(row, auth) that returns a 403 NextResponse when
row.account_id !== auth.accountId or null on success, and create
okSessionResponse(row) that returns the 200 NextResponse with
toSessionResponse(row) and CORS headers; then refactor getSessionByIdHandler to
call validateAuthContext(request), then getSessionOr404(sessionId), then
assertSessionOwnership(row, auth), and finally return okSessionResponse(row),
keeping all response construction in the new helpers and leaving
validateAuthContext, selectSessions, toSessionResponse, and getCorsHeaders usage
intact.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: d19d18ad-6cda-47d9-b4cd-efc848be6c0d

📥 Commits

Reviewing files that changed from the base of the PR and between 6368313 and b2dd017.

⛔ Files ignored due to path filters (1)

• app/api/sessions/[sessionId]/__tests__/route.test.ts is excluded by !**/*.test.*, !**/__tests__/** and included by app/**

📒 Files selected for processing (2)

• app/api/sessions/[sessionId]/route.ts
• lib/sessions/getSessionByIdHandler.ts

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

find app/api -name "route.ts" -type f | head -5

Repository: recoupable/api

Length of output: 218

---

🏁 Script executed:

cat -n app/api/sessions/\[sessionId\]/route.ts

Repository: recoupable/api

Length of output: 1740

---

🏁 Script executed:

# Check if getSessionByIdHandler exists and review its signature
find . -name "getSessionByIdHandler*" -type f

Repository: recoupable/api

Length of output: 98

---

🏁 Script executed:

# Check other API routes to see validation patterns
grep -r "safeParse\|z\.object" app/api --include="*.ts" -l | head -10

Repository: recoupable/api

Length of output: 118

---

🏁 Script executed:

cat -n ./lib/sessions/getSessionByIdHandler.ts

Repository: recoupable/api

Length of output: 2105

---

🏁 Script executed:

cat -n app/api/accounts/artists/route.ts

Repository: recoupable/api

Length of output: 1634

---

🏁 Script executed:

cat -n app/api/accounts/route.ts

Repository: recoupable/api

Length of output: 2536

---

🏁 Script executed:

# Check the validation function pattern
cat -n lib/accounts/validateAddArtistBody.ts

Repository: recoupable/api

Length of output: 1376

---

🏁 Script executed:

# Check another validation function
cat -n lib/accounts/validateCreateAccountBody.ts

Repository: recoupable/api

Length of output: 1407

---

🏁 Script executed:

# Search for other route parameters that might need validation
grep -r "options.params" app/api --include="*.ts" -B 2 -A 2

Repository: recoupable/api

Length of output: 5345

---

🏁 Script executed:

# Check if there are any validation functions for path parameters
find lib -name "validate*" -type f | xargs grep -l "params\|Params" | head -5

Repository: recoupable/api

Length of output: 290

---

🏁 Script executed:

# Check the accounts/[id]/catalogs route to see how it handles params
cat -n app/api/accounts/\[id\]/catalogs/route.ts

Repository: recoupable/api

Length of output: 1149

---

🏁 Script executed:

# Check another parameterized route with handler
cat -n app/api/artists/\[id\]/route.ts | head -50

Repository: recoupable/api

Length of output: 1938

---

🏁 Script executed:

# Check the validateGetAccountParams and validateAccountParams patterns
cat -n lib/accounts/validateGetAccountParams.ts

Repository: recoupable/api

Length of output: 1725

---

🏁 Script executed:

cat -n lib/accounts/validateAccountParams.ts

Repository: recoupable/api

Length of output: 1324

---

🏁 Script executed:

# Search for how other routes with IDs validate their params
grep -r "validateGetAccountParams\|validateAccountParams" app/api --include="*.ts" -B 2 -A 2

Repository: recoupable/api

Length of output: 40

---

🏁 Script executed:

# Search for usage of these validation functions in routes
grep -r "validateGetAccountParams\|validateAccountParams" . --include="*.ts" | grep -v node_modules

Repository: recoupable/api

Length of output: 4885

---

🏁 Script executed:

# Look for session parameter validation patterns
grep -r "sessionId" lib --include="*.ts" -l | head -5

Repository: recoupable/api

Length of output: 280

---

🏁 Script executed:

# Check if there's a pattern for validating route params across the API
grep -r "safeParse.*params\|validateGet.*Params" app/api --include="*.ts" -B 3 -A 3

Repository: recoupable/api

Length of output: 40

---

🏁 Script executed:

# Check if there are tests for the sessions route
find . -name "*sessions*" -type f | grep -i test

Repository: recoupable/api

Length of output: 40

---

🏁 Script executed:

# Look at the getAccountHandler to see the pattern
cat -n lib/accounts/getAccountHandler.ts | head -50

Repository: recoupable/api

Length of output: 1906

---

Add parameter validation for sessionId using Zod before calling the handler.

The route currently forwards the sessionId parameter without validation. Create a validation function following the established pattern in the codebase (similar to validateAccountParams or validateAddArtistBody) that validates the parameter format and returns either the validated value or a NextResponse error.

Proposed validation pattern

 import { NextRequest, NextResponse } from "next/server";
 import { getCorsHeaders } from "@/lib/networking/getCorsHeaders";
 import { getSessionByIdHandler } from "@/lib/sessions/getSessionByIdHandler";
+import { z } from "zod";
+
+const sessionIdParamsSchema = z.object({
+  sessionId: z.string().min(1, "sessionId cannot be empty"),
+});

 export async function GET(
   request: NextRequest,
   options: { params: Promise<{ sessionId: string }> },
 ) {
-  const { sessionId } = await options.params;
-  return getSessionByIdHandler(request, sessionId);
+  const parsed = sessionIdParamsSchema.safeParse(await options.params);
+  if (!parsed.success) {
+    const firstError = parsed.error.issues[0];
+    return NextResponse.json(
+      {
+        status: "error",
+        missing_fields: firstError.path,
+        error: firstError.message,
+      },
+      { status: 400, headers: getCorsHeaders() },
+    );
+  }
+  return getSessionByIdHandler(request, parsed.data.sessionId);
+}

This follows the coding guideline: "All API endpoints should use a validate function for input parsing using Zod for schema validation."

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	export async function GET(
	request: NextRequest,
	options: { params: Promise<{ sessionId: string }> },
	) {
	const { sessionId } = await options.params;
	return getSessionByIdHandler(request, sessionId);
	import { NextRequest, NextResponse } from "next/server";
	import { getCorsHeaders } from "@/lib/networking/getCorsHeaders";
	import { getSessionByIdHandler } from "@/lib/sessions/getSessionByIdHandler";
	import { z } from "zod";
	const sessionIdParamsSchema = z.object({
	sessionId: z.string().min(1, "sessionId cannot be empty"),
	});
	export async function GET(
	request: NextRequest,
	options: { params: Promise<{ sessionId: string }> },
	) {
	const parsed = sessionIdParamsSchema.safeParse(await options.params);
	if (!parsed.success) {
	const firstError = parsed.error.issues[0];
	return NextResponse.json(
	{
	status: "error",
	missing_fields: firstError.path,
	error: firstError.message,
	},
	{ status: 400, headers: getCorsHeaders() },
	);
	}
	return getSessionByIdHandler(request, parsed.data.sessionId);
	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/api/sessions/`[sessionId]/route.ts around lines 32 - 37, Add a Zod-based
parameter validator for sessionId and call it from the GET route before invoking
getSessionByIdHandler: create a function (e.g., validateSessionParams) modeled
after validateAccountParams / validateAddArtistBody that accepts the raw params
object, defines a Zod schema for { sessionId: string } (with any required format
checks), returns the parsed value on success or a NextResponse with a 400 error
on failure, then update the GET handler to await
validateSessionParams(options.params) and only call
getSessionByIdHandler(request, sessionId) when validation passes.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Return a consistent 500 JSON+CORS response on data-layer failures.

selectSessions() errors currently bubble out and can break your consistent envelope/CORS contract for this endpoint.

Proposed fix

 export async function getSessionByIdHandler(
   request: NextRequest,
   sessionId: string,
 ): Promise<NextResponse> {
   const auth = await validateAuthContext(request);
   if (auth instanceof NextResponse) {
     return auth;
   }

-  const rows = await selectSessions({ id: sessionId });
+  let rows;
+  try {
+    rows = await selectSessions({ id: sessionId });
+  } catch {
+    return NextResponse.json(
+      { status: "error", error: "Internal server error" },
+      { status: 500, headers: getCorsHeaders() },
+    );
+  }
   const row = rows[0] ?? null;

As per coding guidelines, “Handle errors gracefully” and for API logic “Proper error handling and validation.”

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const rows = await selectSessions({ id: sessionId });
	const row = rows[0] ?? null;
	if (!row) {
	return NextResponse.json(
	{ status: "error", error: "Session not found" },
	{ status: 404, headers: getCorsHeaders() },
	);
	}
	if (row.account_id !== auth.accountId) {
	return NextResponse.json(
	{ status: "error", error: "Forbidden" },
	{ status: 403, headers: getCorsHeaders() },
	);
	}
	return NextResponse.json(
	{ session: toSessionResponse(row) },
	{ status: 200, headers: getCorsHeaders() },
	);
	export async function getSessionByIdHandler(
	request: NextRequest,
	sessionId: string,
	): Promise<NextResponse> {
	const auth = await validateAuthContext(request);
	if (auth instanceof NextResponse) {
	return auth;
	}
	let rows;
	try {
	rows = await selectSessions({ id: sessionId });
	} catch {
	return NextResponse.json(
	{ status: "error", error: "Internal server error" },
	{ status: 500, headers: getCorsHeaders() },
	);
	}
	const row = rows[0] ?? null;
	if (!row) {
	return NextResponse.json(
	{ status: "error", error: "Session not found" },
	{ status: 404, headers: getCorsHeaders() },
	);
	}
	if (row.account_id !== auth.accountId) {
	return NextResponse.json(
	{ status: "error", error: "Forbidden" },
	{ status: 403, headers: getCorsHeaders() },
	);
	}
	return NextResponse.json(
	{ session: toSessionResponse(row) },
	{ status: 200, headers: getCorsHeaders() },
	);
	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/sessions/getSessionByIdHandler.ts` around lines 30 - 50, selectSessions
can throw and currently bubbles out, breaking the endpoint's JSON+CORS contract;
wrap the call to selectSessions({ id: sessionId }) in a try/catch inside
getSessionByIdHandler (or the handler function in this file), and on any caught
error return a NextResponse.json({ status: "error", error: "Internal server
error" }, { status: 500, headers: getCorsHeaders() }); optionally log the caught
error before returning; keep the rest of the control flow (not-found, forbidden,
success using toSessionResponse(row)) unchanged.