apps/backend/src/app/api/latest/internal/session-replays/[session_replay_id]/route.tsx (1)

47-70: Consider adding UUID validation for session_replay_id parameter.

The sessionReplayId parameter is passed directly to the SQL query without UUID format validation. While Postgres will reject invalid UUIDs, the resulting error would be a database-level error rather than a clean ITEM_NOT_FOUND response. The tenancyId is explicitly cast with ::UUID, but sessionReplayId is not.

This is a minor consistency issue since invalid UUIDs are an edge case, but adding a .uuid() validation to the yup schema or explicit casting in the query would improve error handling.

💡 Optional: Add UUID validation

   request: yupObject({
     auth: yupObject({
       type: adminAuthTypeSchema.defined(),
       tenancy: adaptSchema.defined(),
     }).defined(),
     params: yupObject({
-      session_replay_id: yupString().defined(),
+      session_replay_id: yupString().uuid().defined(),
     }).defined(),
   }),

Or alternatively, add explicit UUID cast in the query:

       WHERE sr."tenancyId" = ${auth.tenancy.id}::UUID
-        AND sr."id" = ${sessionReplayId}
+        AND sr."id" = ${sessionReplayId}::UUID

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/backend/src/app/api/latest/internal/session-replays/`[session_replay_id]/route.tsx
around lines 47 - 70, Validate the session_replay_id as a UUID before using it
in the query: update the parsing/validation logic that produces sessionReplayId
(the yup schema or request param validator used in route.tsx) to include .uuid()
so invalid IDs are rejected with a controlled error, or alternately change the
prisma.$queryRaw call (the query that uses sessionReplayId) to explicitly cast
the parameter to UUID (e.g. ${sessionReplayId}::UUID) so Postgres rejects
invalid input in a consistent way; ensure you reference the sessionReplayId
variable used in the SELECT and keep the rest of the query (including tenancyId
casting) unchanged.

apps/dashboard/src/app/(main)/(protected)/projects/[projectId]/analytics/replays/[replayId]/page.tsx (1)

3-9: Prefer a client-side param reader for this wrapper.

This page only forwards replayId into PageClient, so await props.params is avoidable here. A tiny client wrapper using useParams() would keep this route aligned with the repo’s Next.js guidance and avoid using a dynamic request API just to pass one string.

As per coding guidelines, "NEVER use Next.js dynamic functions if you can avoid them. Instead, prefer using a client component."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/dashboard/src/app/`(main)/(protected)/projects/[projectId]/analytics/replays/[replayId]/page.tsx
around lines 3 - 9, The Page component currently awaits props.params to forward
replayId to PageClient; replace this server-side async wrapper with a client
component that uses Next.js' useParams() to read replayId and render PageClient.
Create a simple client wrapper (export default) that calls useParams(), extracts
replayId, and passes it as initialReplayId to PageClient, remove the
async/Page-level awaiting of props.params and any related server-only signatures
so the route no longer uses dynamic server params.