Conversation
📝 WalkthroughWalkthroughThis PR introduces a complete authentication layer with role-based access control, conversation management system, metrics/KPI tracking, and a full-featured Next.js operator dashboard. Includes API middleware, conversation repositories with timeline operations, multiple new endpoints, Supabase schema extensions for RBAC and escalation workflows, and corresponding front-end pages and components for login, conversations, escalations, and KPI visualization. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant Browser as Browser (Dashboard)
participant NextJS as Next.js App
participant Supabase as Supabase Auth
participant API as Express API
participant DB as Database
User->>Browser: Visit /conversations
Browser->>NextJS: Request page
NextJS->>Supabase: getUser() + fetch role
Supabase->>DB: Query user_roles
DB-->>Supabase: Return role
Supabase-->>NextJS: Return UserSession
alt No Session
NextJS-->>Browser: Redirect to /login
User->>Browser: Enter credentials
Browser->>Supabase: signInWithPassword()
Supabase-->>Browser: Session token
Browser->>NextJS: Redirect home
else Valid Session
NextJS->>API: GET /api/conversations (Bearer token)
API->>API: authenticateRequest middleware
API->>Supabase: getUser(token)
Supabase->>DB: Query user_roles
DB-->>API: Return user role
API->>DB: listActiveConversations()
DB-->>API: Return conversations
API-->>NextJS: JSON response
NextJS-->>Browser: Render conversation list
User->>Browser: Click on conversation
Browser->>NextJS: Request /conversations/[id]
NextJS->>API: GET /api/conversations/{id}/timeline
API->>API: authenticateRequest + requireRole
API->>DB: getConversationTimeline()
DB-->>API: Return timeline
API-->>NextJS: JSON response
NextJS-->>Browser: Render timeline + controls
User->>Browser: Click "Takeover"
Browser->>NextJS: Server action takeoverConversation()
NextJS->>API: POST /api/conversations/{id}/takeover
API->>API: authenticateRequest + requireRole
API->>DB: Update conversation + timeline
DB-->>API: Success
API-->>NextJS: Response
NextJS-->>Browser: Revalidate page
Browser-->>User: UI updated
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 19
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
🟡 Minor comments (12)
supabase/migrations/202603080000_j1_user_roles.sql-48-51 (1)
48-51:⚠️ Potential issue | 🟡 MinorMissing bootstrap mechanism for initial admin role assignment.
The INSERT policy (line 48-51) requires an existing admin to assign roles, creating a chicken-and-egg problem. The seed file at
./scripts/seed/seed-local.sqlis currently a placeholder with no actual data initialization.Consider one of these approaches:
- Add initial admin setup to the seed migration (requires a known user ID)
- Use a service role key bypass for initial setup
- Add a conditional policy allowing self-assignment when no admins exist
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@supabase/migrations/202603080000_j1_user_roles.sql` around lines 48 - 51, The INSERT policy "Admins can insert roles" on public.user_roles currently blocks bootstraping because it requires an existing admin; change the setup so initial admin can be created by either: (A) adding a seed step that inserts a known bootstrap user into public.user_roles before the policy is applied (use the seed file to insert a specific user id), (B) using the service role key to perform the initial INSERT via a migration script or provisioning tool, or (C) relax the policy logic to allow INSERT when no admin exists (e.g., permit INSERT on public.user_roles if public.has_role(auth.uid(),'admin') OR there are zero rows in public.user_roles with role='admin' for the bootstrap actor, optionally restricted to a known bootstrap user id) so the first admin can self-assign and subsequent inserts require public.has_role(auth.uid(),'admin').apps/dashboard/app/layout.tsx-16-18 (1)
16-18:⚠️ Potential issue | 🟡 MinorReplace the default app metadata before shipping.
This still exposes the create-next-app title/description in the browser tab and previews instead of the dashboard branding.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/layout.tsx` around lines 16 - 18, The exported metadata object in layout.tsx currently uses the default Create Next App values (metadata: Metadata with title and description); replace them with your dashboard's actual title and description (or load from app config/env) so browser tabs, previews, and social cards show the correct branding—update the metadata.title and metadata.description in the exported metadata object (and add any relevant openGraph/twitter metadata if available) to the product-specific strings or variables.apps/api/src/routes/conversations.ts-41-41 (1)
41-41:⚠️ Potential issue | 🟡 MinorFallback to 'unknown' operatorId may mask authentication issues.
If
x-wa-userheader is missing, operations proceed with'unknown'as the operator. This could lead to audit trail issues and mask cases where authentication middleware isn't properly passing user identity.🛡️ Recommended: require the header
conversationsRouter.post('/:id/takeover', async (req, res) => { try { - const operatorId = req.header('x-wa-user') || 'unknown'; + const operatorId = req.header('x-wa-user'); + if (!operatorId) { + res.status(401).json({ error: 'Operator identity required' }); + return; + } await conversationRepository.takeoverConversation(req.params.id, operatorId);Also applies to: 51-51, 61-61
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/routes/conversations.ts` at line 41, The code currently falls back to 'unknown' when reading the operator id with const operatorId = req.header('x-wa-user') || 'unknown'; which can hide missing authentication; change this to validate the header and return a 401/400 if it's absent (e.g., if (!req.header('x-wa-user')) { return res.status(401).json({ error: 'Missing operator id' }); }), then set operatorId = req.header('x-wa-user') (no default). Apply the same validation pattern for the other occurrences noted around the operatorId retrievals at the other routes so operations never proceed with a default 'unknown'.apps/api/src/repositories/conversation.test.js-3-54 (1)
3-54:⚠️ Potential issue | 🟡 MinorTests lack isolation due to shared mutable state.
All tests operate on
conv_1and mutate its timeline without cleanup. The order of test execution affects results - for example, the takeover test (line 18-29) adds an event that persists into subsequent tests. If test order changes or tests run in parallel, results become unpredictable.🧪 Recommended fix: reset state before each test
Consider adding a
beforeEachhook to reset the repository state, or use unique conversation IDs per test:+import { beforeEach } from 'vitest'; + describe('ConversationRepository (Mock)', () => { + beforeEach(() => { + // Reset repository to initial state before each test + conversationRepository.reset?.(); // Add a reset method to the mock + }); + it('lists active conversations', async () => {Alternatively, if the mock doesn't support reset, create fresh conversation IDs for mutation tests.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/conversation.test.js` around lines 3 - 54, Tests share and mutate the same conversation (conv_1) causing order-dependent failures; update the suite to reset mock state before each test by adding a beforeEach that calls a reset/seed method on conversationRepository (or recreates conversationRepository) or use unique conversation IDs per test for mutating operations (references: conversationRepository.listActiveConversations, getConversationTimeline, takeoverConversation, returnToBot, addOperatorMessage) so each test runs with isolated data and no cross-test pollution.apps/dashboard/app/conversations/[id]/ConversationActions.tsx-14-24 (1)
14-24:⚠️ Potential issue | 🟡 MinorUnhandled errors in transition callbacks.
If
takeoverConversationorreturnToBotthrows an error, it will be silently swallowed by the transition. Users won't receive feedback when actions fail.🛡️ Proposed fix to handle errors
+import { useState, useTransition } from 'react'; + export function ConversationActions({ conversationId, botActive }: ConversationActionsProps) { const [isPending, startTransition] = useTransition(); + const [error, setError] = useState<string | null>(null); const handleTakeover = () => { + setError(null); startTransition(async () => { - await takeoverConversation(conversationId); + try { + await takeoverConversation(conversationId); + } catch (e) { + setError(e instanceof Error ? e.message : 'Failed to take over'); + } }); }; const handleReturn = () => { + setError(null); startTransition(async () => { - await returnToBot(conversationId); + try { + await returnToBot(conversationId); + } catch (e) { + setError(e instanceof Error ? e.message : 'Failed to return to bot'); + } }); };Then render
errorin the component JSX.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/conversations/`[id]/ConversationActions.tsx around lines 14 - 24, The transition callbacks in handleTakeover and handleReturn swallow thrown errors; wrap the async calls inside try/catch within the startTransition callbacks (in ConversationActions.tsx) and set a component state like [error, setError] to the caught error (or a user-friendly message), clearing it on success; then render the error state in the component JSX so users see feedback when takeoverConversation(conversationId) or returnToBot(conversationId) fails.apps/api/src/routes/conversations.js-13-14 (1)
13-14:⚠️ Potential issue | 🟡 MinorBare catch blocks discard error details.
All catch blocks silently swallow errors without logging. This makes debugging production issues very difficult. Log the error before returning the generic response.
🔧 Example fix for one endpoint
} - catch { + catch (error) { + console.error('Failed to fetch conversations:', error); res.status(500).json({ error: 'Failed to fetch conversations' }); }Also applies to: 22-23, 31-32, 42-43, 52-53, 68-69, 78-79, 92-93
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/routes/conversations.js` around lines 13 - 14, The catch blocks in conversations.js are bare and discard errors; update each to catch the error (e.g., catch (err) or catch (error)) and log it before sending the generic 500 response — for example, inside each route handler (handlers such as the conversation fetch/create/update/delete functions) replace "catch { ... }" with "catch (error) { console.error('Description of action failed', error); res.status(500).json({ error: 'Failed to fetch conversations' }); }" (use an appropriate descriptive message per handler or your app logger instead of console.error); do this for every listed catch site to preserve error details for debugging.apps/dashboard/app/escalations/actions.ts-22-26 (1)
22-26:⚠️ Potential issue | 🟡 MinorMissing JSON parse error handling.
If the API returns a non-JSON response (e.g., HTML error page),
res.json()will throw. Consider adding error handling or checkingContent-Type.🛡️ Proposed defensive handling
if (!res.ok) { - throw new Error(`API error: ${res.statusText}`); + const text = await res.text(); + throw new Error(`API error: ${res.status} - ${text.slice(0, 100)}`); } - return res.json(); + const contentType = res.headers.get('content-type'); + if (!contentType?.includes('application/json')) { + throw new Error('API returned non-JSON response'); + } + return res.json();🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/escalations/actions.ts` around lines 22 - 26, The code currently calls res.json() after checking res.ok, but res.json() can throw if the response is not JSON; wrap the parse in a try/catch and/or check the response Content-Type header before parsing: if content-type includes "application/json" call await res.json() inside try/catch and return the parsed object, otherwise await res.text() and throw a new Error containing the non-JSON body and status (use res.text() as a fallback); ensure you update the logic around the existing res.ok check and the res.json() call in the escalations actions (reference res.json(), res.text(), and the res.ok branch) so errors include helpful context.apps/dashboard/app/escalations/EscalationRow.tsx-24-34 (1)
24-34:⚠️ Potential issue | 🟡 MinorAction errors are silently discarded.
Both
handleAssignandhandleStatusChangeignore the return value from the server actions, which include{ success, error }. Users won't be notified when an assignment or status update fails.🛠️ Proposed fix to surface errors
+import { useState } from 'react'; +// ... in the component: +const [error, setError] = useState<string | null>(null); const handleAssign = (operatorId: string | null) => { startTransition(async () => { - await assignOperatorAction(conv.id, operatorId); + const result = await assignOperatorAction(conv.id, operatorId); + if (!result.success) setError(result.error ?? 'Assignment failed'); }); };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/escalations/EscalationRow.tsx` around lines 24 - 34, Both handlers currently swallow server action results; update handleAssign and handleStatusChange to await the returned { success, error } from assignOperatorAction(conv.id, operatorId) and updateEscalationStatusAction(conv.id, status), check success, and surface failures (e.g., call an existing toast/notification helper or set local error state) when success is false by including the error message; ensure you still perform the action inside startTransition and reference the functions/identifiers handleAssign, handleStatusChange, assignOperatorAction, updateEscalationStatusAction, conv.id, and EscalationStatus so the UI shows feedback on failures.apps/dashboard/lib/supabase/auth.ts-21-32 (1)
21-32:⚠️ Potential issue | 🟡 MinorPotential issues with user data assumptions.
- Line 30:
user.email!assumes email exists, but Supabase users authenticated via phone won't have an email.- Line 26:
.single()throws if no row exists or multiple rows match—this error bubbles up unhandled, causinggetCurrentSessionto throw instead of returningnull.- Line 31: The role is cast to
AppRolewithout validating it's a valid enum value.🛡️ Proposed defensive handling
// Fetch the role from user_roles - const { data: roleData } = await supabase + const { data: roleData, error: roleError } = await supabase .from('user_roles') .select('role') .eq('user_id', user.id) - .single(); + .maybeSingle(); + + if (roleError) { + console.error('Failed to fetch user role:', roleError); + } return { id: user.id, - email: user.email!, + email: user.email ?? '', role: roleData?.role as AppRole | null, };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/lib/supabase/auth.ts` around lines 21 - 32, The code assumes user.email exists, uses .single() which throws on no/multiple rows, and unsafely casts role to AppRole; update the auth function that builds the returned user object to (1) avoid force-nonnull on user.email — return email as string | null (or a sensible fallback) instead of using user.email!; (2) replace the user_roles query's .single() with .maybeSingle() or wrap the query in a try/catch and treat “no row” as roleData = null so the function returns null/partial session instead of throwing; and (3) validate the fetched role before casting (e.g., check the value is one of AppRole enum members) and default to null or a safe role if it isn’t, so you never blindly cast roleData?.role as AppRole.apps/dashboard/middleware.ts-17-24 (1)
17-24:⚠️ Potential issue | 🟡 MinorforEach callbacks should not return values.
The arrow function callbacks implicitly return values from
.set()calls, which is flagged by static analysis. Use block syntax to avoid returning values from forEach callbacks.🔧 Proposed fix
setAll(cookiesToSet) { - cookiesToSet.forEach(({ name, value }) => request.cookies.set(name, value)); + cookiesToSet.forEach(({ name, value }) => { + request.cookies.set(name, value); + }); supabaseResponse = NextResponse.next({ request, }); - cookiesToSet.forEach(({ name, value, options }) => - supabaseResponse.cookies.set(name, value, options), - ); + cookiesToSet.forEach(({ name, value, options }) => { + supabaseResponse.cookies.set(name, value, options); + }); },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/middleware.ts` around lines 17 - 24, The forEach callbacks inside setAll currently use concise arrow bodies and therefore implicitly return the result of request.cookies.set and supabaseResponse.cookies.set, which static analysis flags; modify the two forEach calls in setAll so their callbacks use block bodies (e.g., ({ name, value }) => { request.cookies.set(name, value); }) and ({ name, value, options }) => { supabaseResponse.cookies.set(name, value, options); }) to avoid returning values from the callbacks while preserving the existing behavior around NextResponse.next and request/supabase cookie setting.apps/api/src/auth.ts-78-82 (1)
78-82:⚠️ Potential issue | 🟡 MinorNon-null assertion on
user.emailmay cause runtime errors.Line 80 uses
user.email!but Supabase users can exist without an email (e.g., phone auth, anonymous auth). If such a user authenticates, this will assignundefinedtostring.🛡️ Proposed fix to handle missing email
req.user = { id: user.id, - email: user.email!, + email: user.email ?? '', role: (roleData?.role as AppRole) || null, };Alternatively, make
Request.usertype if the absence is expected.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/auth.ts` around lines 78 - 82, The assignment to req.user uses a non-null assertion on user.email which can crash for phone/anonymous Supabase users; update the req.user construction in the auth middleware to stop using user.email! and instead safely handle missing email (e.g., set email to user.email ?? null or make Request.user.email optional) and adjust the Request.user type accordingly so callers handle a nullable/optional email; locate the req.user = { id: user.id, email: ..., role: ... } block and change the email handling and type definition for Request.user (or callers) to accept null/undefined.apps/api/src/repositories/conversation.ts-148-162 (1)
148-162:⚠️ Potential issue | 🟡 MinorUnused
operatorIdparameter inaddOperatorMessage.The
operatorIdparameter is accepted but never used in the method body. Either remove it from the signature or include it in the message metadata for audit purposes.🔧 Proposed fix to use operatorId
async addOperatorMessage( conversationId: string, operatorId: string, content: string, ): Promise<void> { if (!mockTimeline[conversationId]) mockTimeline[conversationId] = []; mockTimeline[conversationId].push({ type: 'message', id: `msg_op_${Date.now()}`, conversationId, senderRole: 'agent', content, createdAt: new Date().toISOString(), + // Consider adding: operatorId for audit trail when DB is wired }); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/conversation.ts` around lines 148 - 162, The addOperatorMessage function currently accepts operatorId but never uses it; update the message metadata pushed into mockTimeline[conversationId] to include operatorId (e.g., add an operatorId or senderId field) so audit info is preserved, or remove the operatorId parameter if you intentionally don't need it; locate the method named addOperatorMessage and modify the object pushed to mockTimeline to include the operatorId key (or remove the parameter from the signature and all callers if you choose deletion).
🧹 Nitpick comments (25)
apps/dashboard/lib/supabase/server.ts (2)
15-19: Usefor...ofinstead offorEachto avoid implicit return.The static analysis tool correctly flags that
cookieStore.set()returns a value, butforEachcallbacks should not return values. Usingfor...ofis cleaner and avoids this lint issue.♻️ Proposed fix
setAll(cookiesToSet) { try { - cookiesToSet.forEach(({ name, value, options }) => - cookieStore.set(name, value, options), - ); + for (const { name, value, options } of cookiesToSet) { + cookieStore.set(name, value, options); + } } catch {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/lib/supabase/server.ts` around lines 15 - 19, In the setAll method replace the cookiesToSet.forEach(...) usage with an explicit for...of loop to iterate over cookiesToSet and call cookieStore.set(name, value, options) for each item; update the function in the same class/method named setAll so it no longer uses Array.prototype.forEach (which causes an implicit return lint warning) and instead uses: for (const { name, value, options } of cookiesToSet) { cookieStore.set(name, value, options); } ensuring behavior is unchanged.
7-9: Consider validating environment variables at startup.Non-null assertions (
!) on environment variables will cause unclear runtime errors if the variables are missing. Consider validating them at module load or using a configuration helper that fails fast with a descriptive message.♻️ Example validation pattern
const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL; const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY; if (!supabaseUrl || !supabaseAnonKey) { throw new Error('Missing required Supabase environment variables'); } // Then use them without assertions return createServerClient(supabaseUrl, supabaseAnonKey, { ... });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/lib/supabase/server.ts` around lines 7 - 9, Replace the non-null assertions when calling createServerClient with explicit startup validation: read process.env.NEXT_PUBLIC_SUPABASE_URL and process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY into local constants, check they are present (throw a clear Error if not), and then pass those validated constants into createServerClient (so update the call site that currently uses process.env.NEXT_PUBLIC_SUPABASE_URL! and process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!); this ensures createServerClient is invoked only with guaranteed values and produces a descriptive failure at module load.apps/api/src/repositories/metrics.d.ts (1)
1-6: Consider whether this compiled declaration should be committed.This
.d.tsfile has asourceMappingURLindicating it's compiler-generated. If this is intentional for package distribution (enabling consumers to get types without building), ensure it's kept in sync with the source. Otherwise, exclude generated files from version control and let consumers build from source.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/metrics.d.ts` around lines 1 - 6, The committed apps/api/src/repositories/metrics.d.ts appears to be a compiler-generated declaration (note the sourceMappingURL) and should either be managed as a build artifact or intentionally published; decide and act: if it should not be committed, remove metrics.d.ts from the repo, add a rule to .gitignore for the generated declarations (or the build output folder) and commit that change; if it is intentional to ship declarations, instead ensure the source (the implementation containing class MetricsRepository and its method getDashboardKPIs, plus the exported metricsRepository) is the single source of truth and update your build/publish process so the emitted .d.ts is regenerated on build and documented in your release flow so the file stays in sync.apps/api/src/auth.js (1)
1-5: Avoid committing compiled JavaScript artifacts.This file has a
sourceMappingURLcomment (line 76) indicating it's compiled from TypeScript. Consider excluding compiled.jsfiles from version control and building from.tssource files instead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/auth.js` around lines 1 - 5, This file appears to be a compiled JavaScript artifact—remove the committed .js and restore/commit the original TypeScript source instead: delete this compiled file, add a rule to .gitignore to exclude compiled artifacts (e.g., *.js and *.js.map or the specific path), and ensure the project builds the TypeScript source that defines the same exports (createClient usage and the supabase, supabaseUrl, supabaseServiceRoleKey initialization) so runtime imports reference the generated build output only from CI/build steps rather than version control.apps/api/src/repositories/metrics.test.d.ts (1)
1-2: Exclude compiled TypeScript artifacts from version control.This is a generated
.d.tsfile with asourceMappingURLcomment, which is compiler output. A quick scan reveals 16 similar.d.tsfiles are committed across the repository, including test declaration files (metrics.test.d.ts,conversation.test.d.ts, etc.). Generated artifacts should be excluded via.gitignoreand produced during build instead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/metrics.test.d.ts` around lines 1 - 2, Remove committed generated TypeScript declaration artifacts like metrics.test.d.ts (and the other .d.ts test artifacts such as conversation.test.d.ts) from version control and add a gitignore entry to prevent future commits: delete or git-remove them from the repo index (keeping them locally if needed), add a pattern like "*.d.ts.map" and the generated .d.ts pattern used for tests to .gitignore (or add the build output folder), and ensure your build/tsconfig still emits declarations during CI/build so these files are produced at build time rather than stored in source control.apps/api/src/repositories/metrics.ts (1)
4-31: Track the mock implementation for production replacement.The comment on lines 5-6 indicates this is a placeholder. Consider adding a tracked TODO or creating an issue to ensure the real Supabase/BullMQ integration doesn't get forgotten.
Would you like me to help create an issue to track replacing this mock implementation with real telemetry data?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/metrics.ts` around lines 4 - 31, The mocked getDashboardKPIs implementation in metrics.ts is temporary and needs an explicit tracked task so it isn't forgotten; open a ticket in your issue tracker (GitHub/Jira) describing "Replace mock getDashboardKPIs with Supabase/BullMQ telemetry", copy the new issue number/URL into a TODO comment immediately above the getDashboardKPIs function (e.g., "// TODO: ISSUE-1234 Replace mock with real Supabase/BullMQ integration - <issue URL>") and ensure the issue includes acceptance criteria, required metrics (volume, queue, latency, rates), and an assignee or label for follow-up.packages/shared/src/index.js (1)
175-175: EnsureAPP_ROLESstays synchronized with the SQL enum.The roles
['admin', 'support_agent', 'analyst']must match thepublic.app_roleenum in the migration. Consider adding a comment referencing the migration file to help maintainers keep them in sync.+// Keep in sync with supabase/migrations/202603080000_j1_user_roles.sql (app_role enum) export const APP_ROLES = ['admin', 'support_agent', 'analyst'];🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/shared/src/index.js` at line 175, APP_ROLES is hardcoded and must match the SQL enum public.app_role; update the exported APP_ROLES array to exactly mirror the enum values and add an inline comment next to APP_ROLES referencing the migration that defines public.app_role (include the migration filename or identifier), and optionally add a brief reminder to update both places together or add a unit test that validates the JS array equals the enum values fetched or documented in the migration; locate the APP_ROLES export symbol to make this change.apps/api/src/index.test.js (1)
509-514: Consider verifying the error response body for consistency.The test correctly asserts the 401 status code for unauthenticated requests. For consistency with other tests in this file (e.g., lines 274-284), consider also asserting the response body structure.
💡 Optional enhancement
await runTest('GET /api/kpis requires authentication', async () => { await withServer({}, async (baseUrl) => { const res = await fetch(`${baseUrl}/api/kpis`); assert.equal(res.status, 401); + const body = await res.json(); + assert.ok(body.error, 'Expected error object in response'); }); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/index.test.js` around lines 509 - 514, The test for unauthenticated GET /api/kpis currently only asserts res.status === 401; update it to also parse and assert the response JSON shape matches the project convention (e.g., call res.json() and assert properties like error or message exist and have expected values) so it parallels other tests using runTest and withServer; locate the test block using runTest('GET /api/kpis requires authentication', ...) and add assertions against the parsed body to ensure consistent error response structure.apps/api/src/repositories/metrics.test.js (1)
4-13: Consider using more specific assertions for robustness.
toBeDefined()passes fornullvalues, which may not match the expected behavior. For mock validation, this is acceptable, but for stronger guarantees consider usingtoHaveProperty()or type-checking assertions.💡 Optional: more robust assertions
it('should return mocked J4 KPIs', async () => { const kpis = await metricsRepository.getDashboardKPIs(); - expect(kpis.volume).toBeDefined(); - expect(kpis.queue).toBeDefined(); - expect(kpis.latency).toBeDefined(); - expect(kpis.rates).toBeDefined(); - expect(kpis.updatedAt).toBeDefined(); + expect(kpis).toHaveProperty('volume'); + expect(kpis).toHaveProperty('queue'); + expect(kpis).toHaveProperty('latency'); + expect(kpis).toHaveProperty('rates'); + expect(kpis).toHaveProperty('updatedAt'); expect(kpis.queue.dlqCount).toBeGreaterThanOrEqual(0); expect(kpis.volume.totalInbound).toBeGreaterThan(0); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/metrics.test.js` around lines 4 - 13, The current test in metrics.test.js uses toBeDefined() which accepts null; update the assertions for metricsRepository.getDashboardKPIs() to be stricter: replace expect(kpis.volume).toBeDefined() / expect(kpis.queue).toBeDefined() / expect(kpis.latency).toBeDefined() / expect(kpis.rates).toBeDefined() / expect(kpis.updatedAt).toBeDefined() with more specific checks such as expect(kpis).toHaveProperty('volume') and expect(kpis.volume).not.toBeNull(), or use typeof/instance checks (e.g., expect(typeof kpis.updatedAt).toBe('string') or expect(kpis.updatedAt).not.toBeNull()), and ensure numeric fields like kpis.queue.dlqCount and kpis.volume.totalInbound use numeric assertions (toBeGreaterThanOrEqual, toBeGreaterThan) as already present; target functions/classes: metricsRepository.getDashboardKPIs and the test file metrics.test.js.apps/api/src/index.test.ts (1)
645-649: Cover the allow/deny matrix for/api/kpis, not just anonymous access.This only proves unauthenticated requests get 401. Add one authorized case (
analystoradmin) and one authenticated-but-forbidden case so a bad role list can’t slip through.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/index.test.ts` around lines 645 - 649, The test only asserts anonymous requests to /api/kpis return 401; add two more cases to cover the allow/deny matrix: one authenticated+authorized (e.g., role "analyst" or "admin") that calls `${baseUrl}/api/kpis` and asserts a 200 (or expected success) response, and one authenticated-but-forbidden role that asserts a 403. Use the same helpers used here (runTest and withServer) to create the server and attach auth (e.g., set the Authorization header or create a test user/session in withServer), reference the endpoint `/api/kpis` and roles "analyst"/"admin" in the new runTest blocks, and assert the proper status codes for each case so both allowed and denied authenticated paths are covered.apps/api/src/index.js (1)
482-485: Remove the example-only admin route before shipping.The inline comment and
{ ok: true }response make this look like scaffolding, but it still publishes a production admin endpoint. If it’s only here for RBAC smoke tests, keep it in test setup instead.✂️ Suggested cleanup
- // Example RBAC-protected endpoint implementation - app.post('/api/protected/admin-only', authenticateRequest, requireRole('admin'), (req, res) => { - res.json({ ok: true }); - });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/index.js` around lines 482 - 485, Remove the example admin-only route that exposes a production endpoint: delete the app.post('/api/protected/admin-only', authenticateRequest, requireRole('admin'), (req, res) => { res.json({ ok: true }); }) block from apps/api/src/index.js and, if this route is needed only for RBAC smoke tests, move its registration into test setup code (not shipped code) or guard it behind a non-production-only check; ensure you do not remove shared functions authenticateRequest or requireRole if they're used elsewhere.apps/dashboard/lib/supabase/client.ts (1)
3-7: Fail fast on missing public Supabase env vars.The non-null assertions defer a bad deployment config into
createBrowserClient(undefined, undefined), which is much harder to diagnose than an explicit startup error.Suggested fix
export function createClient() { - return createBrowserClient( - process.env.NEXT_PUBLIC_SUPABASE_URL!, - process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!, - ); + const url = process.env.NEXT_PUBLIC_SUPABASE_URL; + const anonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY; + + if (!url || !anonKey) { + throw new Error( + 'Missing NEXT_PUBLIC_SUPABASE_URL or NEXT_PUBLIC_SUPABASE_ANON_KEY', + ); + } + + return createBrowserClient(url, anonKey); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/lib/supabase/client.ts` around lines 3 - 7, The current createClient uses non-null assertions and can call createBrowserClient with undefined; update the createClient function to validate process.env.NEXT_PUBLIC_SUPABASE_URL and process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY at startup and throw a clear Error if either is missing so deployments fail fast; refer to the createClient function and createBrowserClient call and validate the environment variables process.env.NEXT_PUBLIC_SUPABASE_URL and process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY before invoking createBrowserClient.apps/dashboard/app/login/client.tsx (2)
20-21: Non-null assertions on environment variables.Using
!onprocess.env.NEXT_PUBLIC_SUPABASE_URLandprocess.env.NEXT_PUBLIC_SUPABASE_ANON_KEYwill cause runtime errors if these variables are missing. Consider adding validation or a graceful fallback.🛡️ Defensive approach
+ const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL; + const supabaseKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY; + + if (!supabaseUrl || !supabaseKey) { + return <div className="text-red-500">Supabase configuration missing</div>; + } + const supabase = createBrowserClient( - process.env.NEXT_PUBLIC_SUPABASE_URL!, - process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!, + supabaseUrl, + supabaseKey, );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/login/client.tsx` around lines 20 - 21, Replace the non-null assertions on process.env in the Supabase client construction by validating the environment variables at startup and throwing or logging a clear error if they are missing; locate the Supabase client initialization in apps/dashboard/app/login/client.tsx where process.env.NEXT_PUBLIC_SUPABASE_URL and process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY are used, check both values (e.g., if (!url || !key) ...) and either provide a safe fallback or throw a descriptive error/console.error before creating the client so runtime crashes are avoided and configuration problems are obvious.
19-22: Supabase client recreated on every login attempt.Creating the Supabase client inside
handleLoginmeans a new instance is created on every form submission. Move the client creation outside the handler or use a singleton pattern.♻️ Proposed fix to hoist client creation
export default function LoginPageClient() { const router = useRouter(); + const supabase = createBrowserClient( + process.env.NEXT_PUBLIC_SUPABASE_URL!, + process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!, + ); const [email, setEmail] = useState(''); const [password, setPassword] = useState(''); const [loading, setLoading] = useState(false); const [errorMsg, setErrorMsg] = useState(''); const handleLogin = async (e: React.FormEvent) => { e.preventDefault(); setLoading(true); setErrorMsg(''); - const supabase = createBrowserClient( - process.env.NEXT_PUBLIC_SUPABASE_URL!, - process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!, - ); const { error } = await supabase.auth.signInWithPassword({🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/login/client.tsx` around lines 19 - 22, The Supabase client is being recreated on every submit because createBrowserClient is called inside handleLogin; move the call to createBrowserClient out of the handler and instantiate a single client (e.g., at module scope or via a singleton/hook) so the variable supabase is reused across invocations of handleLogin; update references in handleLogin to use the hoisted supabase and ensure environment vars used for createBrowserClient remain validated (or keep the non-null assertions) when you relocate the instantiation.apps/dashboard/app/conversations/actions.ts (1)
30-32: Silent early return may confuse users.When
contentis empty, the function returns silently without any feedback. Consider throwing an error or returning an error state so the UI can inform the user.♻️ Proposed change to provide feedback
export async function sendMessage(conversationId: string, formData: FormData) { const content = formData.get('content') as string; - if (!content) return; + if (!content?.trim()) { + throw new Error('Message content is required'); + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/conversations/actions.ts` around lines 30 - 32, The sendMessage function currently returns silently when content is empty; update its validation to surface an error so the UI can show feedback: when content is falsy, either throw a descriptive Error (e.g. new Error('Message content is required')) or return a structured error object (e.g. { success: false, error: 'Message content is required' }) from sendMessage so callers of sendMessage(conversationId, formData) can detect and display the validation message; ensure the chosen approach is applied where sendMessage is awaited/handled so the UI can present the error to the user.apps/api/src/routes/conversations.ts (1)
15-16: Errors are swallowed without logging.All catch blocks return a 500 response but don't log the actual error. This makes debugging production issues difficult. Consider adding structured error logging.
📊 Proposed fix to add error logging
-conversationsRouter.get('/', async (req, res) => { +conversationsRouter.get('/', async (req, res) => { try { const list = await conversationRepository.listActiveConversations(); res.json(list); - } catch { + } catch (err) { + console.error('[conversations:list]', err); res.status(500).json({ error: 'Failed to fetch conversations' }); } });Apply similar pattern to all catch blocks. For production, consider using a structured logger.
Also applies to: 24-25, 33-34, 44-45, 54-55, 71-72, 81-82, 95-96
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/routes/conversations.ts` around lines 15 - 16, The catch blocks in conversations route currently swallow errors (e.g., the anonymous catch that returns res.status(500).json({ error: 'Failed to fetch conversations' })) — update each catch to capture the error (e.g., catch (err)) and log it before returning the 500 response; for example, call your logger/console.error with context (route name or handler function) and the error, and keep the existing res.status(500).json(...) behavior; apply this change to all similar catch sites that return res.status(500).json (including the blocks around the fetch conversations handler and the other listed catch blocks).apps/api/src/repositories/conversation.test.js (1)
55-55: Remove compiled test artifacts from version control.The repository contains both the TypeScript source (
conversation.test.ts) and its compiled output (conversation.test.jswith source map). Compiled artifacts should not be committed. Add*.jsand*.js.mapfiles to.gitignoreand remove the compiled outputs from version control.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/conversation.test.js` at line 55, Remove the committed compiled test artifacts: delete the generated conversation.test.js and conversation.test.js.map from version control (e.g., git rm --cached or git rm) while keeping the TypeScript source conversation.test.ts; then update .gitignore to ignore compiled test outputs by adding patterns like *.js and *.js.map (or more targeted patterns) so future compiled artifacts aren’t committed. Ensure only the source file conversation.test.ts remains tracked and commit the .gitignore change and the removal of the compiled files.apps/api/src/repositories/conversation.test.ts (2)
21-45: Tests share mutable state and may be order-dependent.The takeover test (line 22) and return-to-bot test (line 35) both mutate
conv_1's timeline. If Vitest runs tests in parallel or in a different order, results become unpredictable. Consider isolating tests by using a fresh conversation ID per test or resetting repository state in abeforeEachhook.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/conversation.test.ts` around lines 21 - 45, The tests mutate shared conversation state (conversationRepository.takeoverConversation and conversationRepository.returnToBot on 'conv_1') causing order-dependent failures; update the tests to isolate state by either resetting the repository in a beforeEach/afterEach or by using unique conversation IDs per test (e.g., generate distinct IDs inside each it block) when calling conversationRepository.takeoverConversation, conversationRepository.returnToBot and conversationRepository.getConversationTimeline so each test operates on a fresh timeline and cannot interfere with others.
27-29: Redundant runtime guards after expect assertions.The
if (!lastEvent || lastEvent.type !== 'event') throw ...guards are unnecessary—the precedingexpectcalls already assert the same conditions and will fail the test if violated. These guards add noise without providing additional safety.♻️ Proposed simplification
expect(lastEvent).toBeDefined(); expect(lastEvent?.type).toBe('event'); - if (!lastEvent || lastEvent.type !== 'event') { - throw new Error('Expected the last timeline item to be an event'); - } + // Type narrowing via assertion - TypeScript knows lastEvent is defined and type is 'event' expect(lastEvent.eventType).toBe('routing_decision');Also applies to: 40-42
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/conversation.test.ts` around lines 27 - 29, Remove the redundant runtime guard blocks that throw when lastEvent is missing or wrong type in the test: the prior expect(...) assertions already validate those conditions, so delete the if (!lastEvent || lastEvent.type !== 'event') { throw new Error('Expected the last timeline item to be an event'); } checks (and the analogous check around lines 40-42). Leave the existing expect(...) assertions intact and ensure no other code depends on those thrown Errors.apps/dashboard/app/escalations/EscalationRow.tsx (1)
79-84: Operator list is hardcoded.The operator options are hardcoded, making it difficult to maintain as operators change. Consider fetching the operator list from the API or passing it as a prop from a parent component.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/escalations/EscalationRow.tsx` around lines 79 - 84, The operator <select> in EscalationRow.tsx is hardcoded; update the component to accept a dynamic operator list (e.g., a prop named operators: Array<{id:string,name:string}>) or fetch operators from the API inside the EscalationRow component (using useEffect and an async fetchOperators function) and render <option> elements by mapping over that array instead of the static entries; ensure the select's value and onChange still work with the existing state/props (keep the select name/handler) and add a fallback option like "Unassigned" when the list is empty.apps/dashboard/middleware.ts (1)
9-11: Environment variables accessed with non-null assertions.Using
!onprocess.env.NEXT_PUBLIC_SUPABASE_URLandNEXT_PUBLIC_SUPABASE_ANON_KEYwill cause a runtime crash if these variables are missing. Consider validating them at startup or providing a more informative error.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/middleware.ts` around lines 9 - 11, The code uses non-null assertions on process.env.NEXT_PUBLIC_SUPABASE_URL and process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY when calling createServerClient in middleware.ts, which will crash without a helpful message; replace the ! assertions by validating these env vars before calling createServerClient (e.g., read process.env.NEXT_PUBLIC_SUPABASE_URL and process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY into locals, check for falsy values and throw or log an informative error that names the missing variable(s) so startup clearly fails with context), or provide a safe fallback strategy — update the call site to pass validated values rather than using non-null assertions.apps/dashboard/app/conversations/page.tsx (1)
73-75: toLocaleString() produces inconsistent output across environments.Server-side rendering with
toLocaleString()may produce different date formats depending on the server's locale settings. Consider using a date formatting library (e.g.,date-fns) or specifying explicit locale/options for consistent output.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/dashboard/app/conversations/page.tsx` around lines 73 - 75, The span rendering conv.lastMessageAt uses toLocaleString(), which yields inconsistent formats across environments; replace it with a deterministic formatter (e.g., import format from date-fns and call format(new Date(conv.lastMessageAt), 'yyyy-MM-dd HH:mm:ss') or another explicit pattern) so the output is consistent server- and client-side; update the JSX in page.tsx where conv.lastMessageAt is rendered to use the chosen formatter and ensure you parse the timestamp to a Date first.apps/api/src/repositories/conversation.ts (2)
121-128:Date.now()for IDs may cause collisions under concurrent calls.Using
Date.now()for event/message IDs (e.g.,evt_takeover_${Date.now()}) can produce duplicates if multiple operations occur within the same millisecond. For the mock this is low-risk, but consider using a UUID or counter when wiring to DB.Also applies to: 137-144, 154-161
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/conversation.ts` around lines 121 - 128, The mockTimeline event IDs use Date.now() (e.g., `evt_takeover_${Date.now()}`) which can collide under concurrent calls; replace Date.now()-based IDs with a collision-safe generator (UUID or an incrementing counter) when creating events/messages in functions that push into `mockTimeline[conversationId]` (look for `evt_takeover_...` and similar ID patterns), and apply the same change to the other event/message constructions that currently use Date.now() so all mock IDs (including the ones at the other occurrences referenced) use the chosen UUID/counter generator.
115-130: Mutation methods silently no-op when conversation not found.Methods like
takeoverConversation,returnToBot,assignConversationOwner, andupdateEscalationStatussilently do nothing if the conversation ID doesn't exist. For the mock this may be acceptable, but when wiring to a real DB, consider throwing or returning a result indicating whether the operation succeeded.Also applies to: 132-146, 164-169, 171-179
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/repositories/conversation.ts` around lines 115 - 130, The mutation methods (takeoverConversation, returnToBot, assignConversationOwner, updateEscalationStatus) currently silently no-op when the conversation ID is missing; change each to return a clear success indicator (e.g., change signature to Promise<boolean>), return false immediately if mockConversations.find(...) yields no conversation, and return true after performing the update and pushing to mockTimeline; update callers/tests accordingly so they can handle failure instead of silently ignoring it. Ensure you update the function signatures for takeoverConversation, returnToBot, assignConversationOwner, and updateEscalationStatus and preserve existing timeline logging when returning true.apps/api/src/auth.ts (1)
72-76: Role fetch error is logged but request proceeds without explicit handling.When
roleErroroccurs (and is notPGRST116), the error is logged but the user is still attached withrole: null. This is likely intentional (fail-open for role lookup), but consider whether a 500 response would be more appropriate for unexpected DB errors to avoid granting access with unknown role state.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api/src/auth.ts` around lines 72 - 76, The current check logs non-PGRST116 roleError but continues with user attached as role: null; change this to fail closed for unexpected DB errors by returning a 500 (or throwing) instead of proceeding: in the same handler/middleware where roleError is checked (the block referencing roleError and 'PGRST116' and the user attached with role: null), after logging the error call res.status(500).json({ error: 'Error fetching user role' }) (or throw the error) so the request is terminated and an unknown role is not allowed to continue.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 490139ee-3a99-4c77-8bcf-94e9d01ba813
⛔ Files ignored due to path filters (29)
apps/api/src/auth.d.ts.mapis excluded by!**/*.mapapps/api/src/auth.js.mapis excluded by!**/*.mapapps/api/src/auth.test.d.ts.mapis excluded by!**/*.mapapps/api/src/auth.test.js.mapis excluded by!**/*.mapapps/api/src/index.d.ts.mapis excluded by!**/*.mapapps/api/src/index.js.mapis excluded by!**/*.mapapps/api/src/index.test.d.ts.mapis excluded by!**/*.mapapps/api/src/index.test.js.mapis excluded by!**/*.mapapps/api/src/repositories/conversation.d.ts.mapis excluded by!**/*.mapapps/api/src/repositories/conversation.js.mapis excluded by!**/*.mapapps/api/src/repositories/conversation.test.d.ts.mapis excluded by!**/*.mapapps/api/src/repositories/conversation.test.js.mapis excluded by!**/*.mapapps/api/src/repositories/index.test.d.ts.mapis excluded by!**/*.mapapps/api/src/repositories/index.test.js.mapis excluded by!**/*.mapapps/api/src/repositories/metrics.d.ts.mapis excluded by!**/*.mapapps/api/src/repositories/metrics.js.mapis excluded by!**/*.mapapps/api/src/repositories/metrics.test.d.ts.mapis excluded by!**/*.mapapps/api/src/repositories/metrics.test.js.mapis excluded by!**/*.mapapps/api/src/routes/conversations.d.ts.mapis excluded by!**/*.mapapps/api/src/routes/conversations.js.mapis excluded by!**/*.mapapps/api/src/routes/kpis.d.ts.mapis excluded by!**/*.mapapps/api/src/routes/kpis.js.mapis excluded by!**/*.mappackage-lock.jsonis excluded by!**/package-lock.jsonpackages/shared/src/conversations.d.ts.mapis excluded by!**/*.mappackages/shared/src/conversations.js.mapis excluded by!**/*.mappackages/shared/src/index.d.ts.mapis excluded by!**/*.mappackages/shared/src/index.js.mapis excluded by!**/*.mappackages/shared/src/metrics.d.ts.mapis excluded by!**/*.mappackages/shared/src/metrics.js.mapis excluded by!**/*.map
📒 Files selected for processing (62)
apps/api/src/auth.d.tsapps/api/src/auth.jsapps/api/src/auth.test.d.tsapps/api/src/auth.test.jsapps/api/src/auth.test.tsapps/api/src/auth.tsapps/api/src/index.jsapps/api/src/index.test.d.tsapps/api/src/index.test.jsapps/api/src/index.test.tsapps/api/src/index.tsapps/api/src/repositories/conversation.d.tsapps/api/src/repositories/conversation.jsapps/api/src/repositories/conversation.test.d.tsapps/api/src/repositories/conversation.test.jsapps/api/src/repositories/conversation.test.tsapps/api/src/repositories/conversation.tsapps/api/src/repositories/index.test.d.tsapps/api/src/repositories/index.test.jsapps/api/src/repositories/index.test.tsapps/api/src/repositories/metrics.d.tsapps/api/src/repositories/metrics.jsapps/api/src/repositories/metrics.test.d.tsapps/api/src/repositories/metrics.test.jsapps/api/src/repositories/metrics.test.tsapps/api/src/repositories/metrics.tsapps/api/src/routes/conversations.d.tsapps/api/src/routes/conversations.jsapps/api/src/routes/conversations.tsapps/api/src/routes/kpis.d.tsapps/api/src/routes/kpis.jsapps/api/src/routes/kpis.tsapps/dashboard/app/actions.tsapps/dashboard/app/conversations/[id]/ConversationActions.tsxapps/dashboard/app/conversations/[id]/page.tsxapps/dashboard/app/conversations/actions.tsapps/dashboard/app/conversations/page.tsxapps/dashboard/app/escalations/EscalationRow.tsxapps/dashboard/app/escalations/actions.tsapps/dashboard/app/escalations/page.tsxapps/dashboard/app/layout.tsxapps/dashboard/app/login/client.tsxapps/dashboard/app/login/page.tsxapps/dashboard/app/page.tsxapps/dashboard/components/kpi-card.tsxapps/dashboard/components/kpi-dashboard.tsxapps/dashboard/lib/supabase/auth.tsapps/dashboard/lib/supabase/client.tsapps/dashboard/lib/supabase/server.tsapps/dashboard/middleware.tsapps/dashboard/package.jsonpackages/shared/src/conversations.d.tspackages/shared/src/conversations.jspackages/shared/src/conversations.tspackages/shared/src/index.d.tspackages/shared/src/index.jspackages/shared/src/index.tspackages/shared/src/metrics.d.tspackages/shared/src/metrics.jspackages/shared/src/metrics.tssupabase/migrations/202603080000_j1_user_roles.sqlsupabase/migrations/202603081200_j3_escalation_workflow.sql
| const supabaseUrl = process.env.SUPABASE_URL || 'http://localhost:54321'; | ||
| const supabaseServiceRoleKey = process.env.SUPABASE_SERVICE_KEY || 'dummy'; |
There was a problem hiding this comment.
Remove the fallback for SUPABASE_SERVICE_KEY.
Using 'dummy' as a fallback for the service role key is risky—in production, a misconfigured environment would silently use an invalid key. For security-critical credentials, fail fast if the variable is missing rather than falling back to a placeholder.
🛡️ Proposed fix
const supabaseUrl = process.env.SUPABASE_URL || 'http://localhost:54321';
-const supabaseServiceRoleKey = process.env.SUPABASE_SERVICE_KEY || 'dummy';
+const supabaseServiceRoleKey = process.env.SUPABASE_SERVICE_KEY;
+if (!supabaseServiceRoleKey) {
+ throw new Error('SUPABASE_SERVICE_KEY environment variable is required');
+}📝 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.
| const supabaseUrl = process.env.SUPABASE_URL || 'http://localhost:54321'; | |
| const supabaseServiceRoleKey = process.env.SUPABASE_SERVICE_KEY || 'dummy'; | |
| const supabaseUrl = process.env.SUPABASE_URL || 'http://localhost:54321'; | |
| const supabaseServiceRoleKey = process.env.SUPABASE_SERVICE_KEY; | |
| if (!supabaseServiceRoleKey) { | |
| throw new Error('SUPABASE_SERVICE_KEY environment variable is required'); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/src/auth.js` around lines 2 - 3, The code currently sets
supabaseServiceRoleKey = process.env.SUPABASE_SERVICE_KEY || 'dummy' which
silently falls back to a placeholder; change this to fail-fast by removing the
'dummy' fallback and throwing an explicit error if
process.env.SUPABASE_SERVICE_KEY is undefined or empty (e.g., check
process.env.SUPABASE_SERVICE_KEY and, when falsy, throw a clear Error before
using supabaseServiceRoleKey). Update references to supabaseServiceRoleKey
accordingly so the app cannot start with a missing service key.
| // Fetch role | ||
| const { data: roleData, error: roleError } = await supabase | ||
| .from('user_roles') | ||
| .select('role') | ||
| .eq('user_id', user.id) | ||
| .single(); | ||
| if (roleError && roleError.code !== 'PGRST116') { | ||
| // PGRST116 is the "Result contains 0 rows" error, meaning no role assigned. | ||
| // Other errors are genuine issues | ||
| console.error('Error fetching user role:', roleError); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if user_roles table has a unique constraint on user_id
rg -A 10 'user_roles' --glob '*.sql' | grep -i 'unique\|primary'Repository: Ryanakml/ChatFuse
Length of output: 235
Fix potential bug when users have multiple roles.
The .single() call will error if a user has multiple entries in user_roles. The database schema allows multiple roles per user (UNIQUE(user_id, role) constraint, not UNIQUE(user_id)), so this scenario is valid. Use .maybeSingle() if at most one role is expected, or fetch all roles with the full result set and handle multiple values accordingly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/src/auth.js` around lines 36 - 46, The current Supabase query using
.single() when fetching user roles (the query that assigns { data: roleData,
error: roleError } from supabase.from('user_roles').select('role').eq('user_id',
user.id).single()) will throw if a user has multiple role rows; change the query
to either use .maybeSingle() if you truly expect at most one role, or remove
.single() and fetch all roles (handle an array in roleData) and then
resolve/select the desired role(s). Update downstream logic that reads roleData
to handle an array of roles (or the possibly-null value from .maybeSingle()) and
adjust error handling for roleError accordingly.
| app.use('/api/conversations', conversationsRouter); | ||
| app.use('/api/kpis', kpisRouter); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== createApp router mounts =="
sed -n '260,520p' apps/api/src/index.js
echo
echo "== route handlers reading req.body =="
rg -nP --type=ts --type=js '\b(?:req|request)\.body\b' apps/api/src/routes
echo
echo "== JSON parser usage in app/routes =="
rg -nP --type=ts --type=js 'express\.json\(|\.use\(\s*express\.json\(' apps/api/src/index.js apps/api/src/routesRepository: Ryanakml/ChatFuse
Length of output: 11454
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== conversationsRouter structure (conversations.js) =="
head -100 apps/api/src/routes/conversations.js
echo
echo "== conversationsRouter structure (conversations.ts) =="
head -100 apps/api/src/routes/conversations.ts
echo
echo "== Check for express.json or body parser in router files =="
rg -n 'express\.json|\.use.*json|body.?parser' apps/api/src/routes/conversations.*Repository: Ryanakml/ChatFuse
Length of output: 7102
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Full router mount section of index.js =="
sed -n '480,520p' apps/api/src/index.js
echo
echo "== Any app.use calls before router mounts =="
grep -n "app.use" apps/api/src/index.js | head -20Repository: Ryanakml/ChatFuse
Length of output: 1900
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Middleware setup before router mounts (lines 360-490) =="
sed -n '360,490p' apps/api/src/index.jsRepository: Ryanakml/ChatFuse
Length of output: 5263
Add JSON body parser to /api/conversations routes.
The conversationsRouter has three POST handlers that read req.body (/:id/messages, /:id/assign, /:id/status), but express.json() is only attached to the /webhook endpoint. These handlers will receive undefined for their body properties.
Add app.use(express.json()) before the router mount, or configure the parser inside the router:
app.use(express.json());
app.use('/api/conversations', conversationsRouter);
app.use('/api/kpis', kpisRouter);
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/src/index.js` around lines 486 - 487, The conversations routes mount
is missing a JSON body parser so POST handlers on conversationsRouter (handlers
for routes like '/:id/messages', '/:id/assign', '/:id/status') will get
undefined req.body; fix by registering express.json() before mounting
conversationsRouter (or add the parser inside the conversationsRouter itself) so
that app.use(express.json()) is called prior to app.use('/api/conversations',
conversationsRouter) ensuring req.body is populated for those POST handlers.
| import assert from 'node:assert/strict'; | ||
| import { createHmac } from 'node:crypto'; | ||
| import { INGRESS_JOB_SCHEMA_VERSION } from '@wa-chat/shared'; | ||
| import './repositories/index.test.js'; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== package scripts =="
fd '^package\.json$' -x sh -c 'echo "## $1"; sed -n "1,220p" "$1"; echo' sh {}
echo "== runner clues in package scripts and test files =="
rg -n --glob 'package.json' --glob 'apps/api/src/**/*.ts' --glob 'apps/api/src/**/*.js' 'vitest|index\.test|process\.exit|runTest\('
echo
echo "== ad-hoc API test entrypoint =="
sed -n '1,40p' apps/api/src/index.test.ts
echo
echo "== imported repository test aggregator =="
sed -n '1,80p' apps/api/src/repositories/index.test.tsRepository: Ryanakml/ChatFuse
Length of output: 13291
This import will fail: apps/api has no Vitest dependency.
The test script runs via node --import tsx, not vitest run. Line 4 imports ./repositories/index.test.js, which contains import { describe, it, expect } from 'vitest'. Since Vitest is not in apps/api/package.json devDependencies, this import will throw a module-not-found error when the test runs.
Either add Vitest to apps/api and migrate the test file to use Vitest discovery, or remove the side-effect import of Vitest suites and keep the ad-hoc runTest harness self-contained.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/src/index.test.ts` at line 4, The import of
'./repositories/index.test.js' pulls in Vitest globals (describe/it/expect) but
apps/api has no Vitest dependency, so either add Vitest as a devDependency or
stop importing the Vitest suite; to fix quickly remove the side-effect import in
index.test.ts and instead make repository tests expose a callable entry (e.g.,
export a runTests or registerTests function from the module that index.test.ts
can import and invoke from your existing runTest harness), or alternatively add
'vitest' to apps/api devDependencies and keep the import so Vitest globals
resolve.
| // Mocked implementation for now to satisfy J4 specs without raw db queries | ||
| // In production, this pulls from Supabase and BullMQ telemetry | ||
| return { | ||
| volume: { | ||
| totalInbound: 1250, | ||
| totalOutbound: 1180, | ||
| }, | ||
| queue: { | ||
| activeJobs: 12, | ||
| waitingJobs: 5, | ||
| failedJobs: 2, | ||
| dlqCount: 0, | ||
| }, | ||
| latency: { | ||
| p50: 850, | ||
| p90: 1200, | ||
| p95: 1450, | ||
| p99: 2100, | ||
| }, | ||
| rates: { | ||
| fallbackRate: 0.02, | ||
| escalationRate: 0.05, | ||
| totalEscalations: 15, | ||
| }, | ||
| updatedAt: new Date().toISOString(), | ||
| }; |
There was a problem hiding this comment.
Don’t ship the live KPI repository with hard-coded numbers.
This makes /api/kpis return fabricated ops data in every environment, and Line 27 makes it look current. At minimum, gate the mock behind an explicit non-production flag; ideally wire this to the real telemetry sources before release.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/src/repositories/metrics.js` around lines 3 - 28, The file currently
returns hard-coded KPI values (the mocked return block with volume, queue,
latency, rates, updatedAt) which must not be exposed in production; update the
function that currently returns this mocked object to only return these static
values when an explicit non-production flag is set (e.g.,
process.env.USE_MOCK_KPIS === 'true' or NODE_ENV !== 'production'), otherwise
call the real telemetry sources (Supabase/BullMQ fetch functions) or throw/log
and return an empty/placeholder response; also avoid fabricating updatedAt in
production (remove or set to the actual telemetry timestamp) and make the gating
conditional around the mocked return so volume/queue/latency/rates are never
hard-coded in production.
| const res = await fetch('http://localhost:3001/api/conversations/escalations', { | ||
| headers: { | ||
| 'x-wa-user': 'ops-admin', | ||
| 'x-wa-role': 'admin', | ||
| }, |
There was a problem hiding this comment.
Do not impersonate an admin from the page layer.
Every request to this page is currently sent as ops-admin with the admin role, so the viewer’s actual identity is ignored and RBAC is bypassed. The hard-coded localhost origin also makes this fail outside local dev.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/dashboard/app/escalations/page.tsx` around lines 6 - 10, The fetch call
in page.tsx is impersonating an admin by sending hard-coded headers ('x-wa-user'
and 'x-wa-role') to a localhost backend and will bypass RBAC and fail outside
dev; remove these hard-coded headers and instead forward the real viewer
identity (e.g., pull the authenticated user/role from your server-side session
or auth context) when calling the backend, and use a relative or
environment-based URL rather than 'http://localhost:3001' so it works in
production; update the fetch invocation (the call to
fetch('http://localhost:3001/api/conversations/escalations', { headers: {
'x-wa-user': ..., 'x-wa-role': ... } })) to derive headers from the
authenticated session/token or to send credentials as appropriate.
| if (!res.ok) { | ||
| throw new Error(`API error: ${res.status}`); | ||
| } | ||
| return res.json(); | ||
| } catch (error) { | ||
| console.error('Failed to fetch escalations:', error); | ||
| return []; |
There was a problem hiding this comment.
Don’t convert fetch failures into “Inbox Zero”.
On auth errors, API outages, or bad config, this falls back to [] and then renders “No active escalations. Inbox Zero! 🎉”. That masks real incidents as an empty queue.
Also applies to: 42-43
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/dashboard/app/escalations/page.tsx` around lines 13 - 19, The current
catch block that does console.error('Failed to fetch escalations:', error) and
returns [] swallows real errors and causes the UI to show "No active
escalations. Inbox Zero! 🎉"; instead, stop converting fetch failures into an
empty list—either rethrow the error (so Next/React error boundaries or calling
code can show an error state) or return a distinct error sentinel (e.g., null or
an Error result) and update the caller to render an error UI rather than the
“Inbox Zero” message; change the catch that returns [] (and the other similar
catch that also returns []) to propagate the failure and ensure the component
rendering logic checks for an error/sentinel and displays an appropriate error
message or retry UI.
| export default function LoginPage({ | ||
| searchParams, | ||
| }: { | ||
| searchParams: { message?: string; error?: string }; | ||
| }) { |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Next.js 15 searchParams async Promise breaking change
💡 Result:
In Next.js 15 (App Router), searchParams passed to page.tsx is now a Promise (same for params), which is a breaking change if your page code expects a plain object. This is part of Next 15’s “Async Request APIs” change. [1][2]
What breaks
Code like this (Next 14-style) will start failing type-checks / builds:
export default function Page({ searchParams }) {
const q = searchParams.q
}Fix (Server Component page)
Make the page async and await:
type SearchParams = Promise<{ [key: string]: string | string[] | undefined }>
export default async function Page(props: { searchParams: SearchParams }) {
const searchParams = await props.searchParams
const q = searchParams.q
}This is the pattern shown in the official Next.js 15 upgrade guide. [1]
Fix (Client Component page)
If your page is a Client Component ('use client'), unwrap with React’s use():
'use client'
import { use } from 'react'
export default function Page(props: { searchParams: Promise<any> }) {
const searchParams = use(props.searchParams)
}(Also shown in the upgrade guide.) [1]
Notes / common gotcha
Next.js 15 may still appear to let you read properties directly off the Promise for migration, but with certain settings (e.g. cacheComponents) this becomes an error—so you should fully migrate to await / use(). [3]
Migration help
Run the Next codemod and then fix any leftovers it flags. [1][3]
Sources:
[1] Next.js “Upgrading: Version 15” guide (Async Request APIs; searchParams in page.js now Promise)
[2] Next.js GitHub issue #70899 (breaking change: searchParams now a Promise)
[3] Next.js error doc: “Cannot access Request information synchronously…” (explains Promises + migration behavior)
🏁 Script executed:
cat -n apps/dashboard/app/login/page.tsxRepository: Ryanakml/ChatFuse
Length of output: 1096
Make LoginPage async and await searchParams for Next.js 15 compatibility.
In Next.js 15, searchParams is now a Promise and must be awaited before accessing its properties. The current synchronous access pattern will cause runtime errors.
🐛 Proposed fix to await searchParams
-export default function LoginPage({
- searchParams,
-}: {
- searchParams: { message?: string; error?: string };
-}) {
+export default async function LoginPage({
+ searchParams,
+}: {
+ searchParams: Promise<{ message?: string; error?: string }>;
+}) {
+ const params = await searchParams;
return (
<div className="flex h-screen items-center justify-center bg-gray-50 px-4">
<div className="w-full max-w-md p-8 bg-white rounded shadow text-black">
<h1 className="text-2xl font-bold mb-6 text-center">WA Chat Login</h1>
- {searchParams?.error && (
- <div className="mb-4 bg-red-100 text-red-700 p-3 rounded">{searchParams.error}</div>
+ {params?.error && (
+ <div className="mb-4 bg-red-100 text-red-700 p-3 rounded">{params.error}</div>
)}
- {searchParams?.message && (
- <div className="mb-4 bg-green-100 text-green-700 p-3 rounded">{searchParams.message}</div>
+ {params?.message && (
+ <div className="mb-4 bg-green-100 text-green-700 p-3 rounded">{params.message}</div>
)}
<LoginPageClient />
</div>
</div>
);
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/dashboard/app/login/page.tsx` around lines 7 - 11, Make the LoginPage
function async and await the incoming searchParams Promise before using its
properties: change the LoginPage signature to async and inside the function do
const params = await searchParams (or similar) then use params.message /
params.error when rendering; update any references to searchParams in LoginPage
to use the awaited value so it works with Next.js 15’s Promise-based
searchParams.
| export interface MessageVolumeKPI { | ||
| totalInbound: number; | ||
| totalOutbound: number; | ||
| } | ||
| export interface QueueHealthKPI { | ||
| activeJobs: number; | ||
| waitingJobs: number; | ||
| failedJobs: number; | ||
| dlqCount: number; | ||
| } | ||
| export interface LatencyPercentilesKPI { | ||
| p50: number; | ||
| p90: number; | ||
| p95: number; | ||
| p99: number; | ||
| } | ||
| export interface FallbackAndEscalationKPI { | ||
| fallbackRate: number; | ||
| escalationRate: number; | ||
| totalEscalations: number; | ||
| } | ||
| export interface OpsDashboardKPIs { | ||
| volume: MessageVolumeKPI; | ||
| queue: QueueHealthKPI; | ||
| latency: LatencyPercentilesKPI; | ||
| rates: FallbackAndEscalationKPI; | ||
| updatedAt: string; | ||
| } | ||
| //# sourceMappingURL=metrics.d.ts.map No newline at end of file |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if .d.ts files are in .gitignore
rg '\.d\.ts' .gitignore || echo "No .d.ts ignore patterns found"
# Check tsconfig for declaration generation
fd -t f 'tsconfig' -x cat {} \; | rg -i '"declaration"' -A1 -B1Repository: Ryanakml/ChatFuse
Length of output: 483
🏁 Script executed:
# Check if .d.ts files are tracked in git
git ls-files | grep '\.d\.ts' | head -20
# Check the package.json for build configuration
find . -maxdepth 3 -name 'package.json' -type f | xargs grep -l '"build"' | head -5
# Look at the structure of the relevant package
cat packages/shared/package.json 2>/dev/null || echo "File not found"Repository: Ryanakml/ChatFuse
Length of output: 1196
🏁 Script executed:
# Check if dist directory exists and what's in it
find . -type d -name 'dist' | head -10
# Check the actual output location in tsconfig for the shared package
find packages/shared -name 'tsconfig*.json' -exec cat {} \;
# Check if there's an outDir configuration
fd -t f 'tsconfig' -path '*/packages/shared/*' -exec cat {} \; | head -100Repository: Ryanakml/ChatFuse
Length of output: 797
🏁 Script executed:
# Verify the specific file from the review exists
ls -la packages/shared/src/metrics.d.ts
# Check how many .d.ts files are in src/ directories
find packages/shared/src -name '*.d.ts' | wc -l
# List them to confirm
find packages/shared/src -name '*.d.ts' | head -20Repository: Ryanakml/ChatFuse
Length of output: 275
Remove generated .d.ts files from version control and update .gitignore.
The .d.ts files in packages/shared/src/ are auto-generated by TypeScript (configured with "declaration": true and "outDir": "./dist"). They should not be committed to git. These files belong only in the dist/ directory after compilation.
Remove the following from the repository:
packages/shared/src/metrics.d.tspackages/shared/src/conversations.d.tspackages/shared/src/index.d.tspackages/shared/src/rag.d.ts
Add **/*.d.ts and **/*.d.ts.map to .gitignore to prevent future accidental commits of generated files.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/shared/src/metrics.d.ts` around lines 1 - 29, The repository
currently tracks generated TypeScript declaration files (e.g.,
packages/shared/src/metrics.d.ts containing interfaces like MessageVolumeKPI,
QueueHealthKPI, LatencyPercentilesKPI, FallbackAndEscalationKPI,
OpsDashboardKPIs); remove those generated .d.ts files (remove
packages/shared/src/metrics.d.ts, conversations.d.ts, index.d.ts, rag.d.ts) from
git and commit the removals, then update .gitignore to add patterns **/*.d.ts
and **/*.d.ts.map so future generated declaration files (and their source maps)
under src/ are ignored and only the compiled dist/ declarations are tracked as
intended.
| -- Migration: Add fields to conversations for Escalation Workflow (J3) | ||
|
|
||
| -- 1. Create enum for escalation status | ||
| CREATE TYPE public.escalation_status A S ENUM ('open', 'pending', 'resolved'); |
There was a problem hiding this comment.
Syntax error: extra space in A S ENUM.
There's a typo on this line—A S ENUM should be AS ENUM. This will cause the migration to fail.
🐛 Proposed fix
--- 3. Create enum for escalation status
-CREATE TYPE public.escalation_status A S ENUM ('open', 'pending', 'resolved');
+CREATE TYPE public.escalation_status AS ENUM ('open', 'pending', 'resolved');📝 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.
| CREATE TYPE public.escalation_status A S ENUM ('open', 'pending', 'resolved'); | |
| CREATE TYPE public.escalation_status AS ENUM ('open', 'pending', 'resolved'); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@supabase/migrations/202603081200_j3_escalation_workflow.sql` at line 4, The
CREATE TYPE statement for the enum escalation_status contains a typo "A S ENUM"
which causes a syntax error; update the CREATE TYPE statement for
escalation_status to use the correct keyword "AS ENUM" (i.e., change "CREATE
TYPE public.escalation_status A S ENUM ('open', 'pending', 'resolved');" to use
"AS ENUM") so the migration will run successfully.
1 participant
Summary by CodeRabbit
New Features
Tests