User N8N workflows [WIP] #599
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Reviewer's GuideIntroduces initial data model and Hasura metadata for user-specific OAuth connections, n8n credentials, and workflows (currently Gmail-focused), while cleaning up some legacy relationships/permissions and regenerating GraphQL schema artifacts. ER diagram for new user OAuth, n8n credential, and workflow tableserDiagram
user {
uuid user_id PK
}
user_oauth_connections {
uuid id PK
uuid user_id FK
text provider
text service
text scopes
text status
timestamptz connected_at
timestamptz revoked_at
}
n8n_credentials {
uuid id PK
uuid user_id FK
text provider
text service
text n8n_credential_id
timestamptz created_at
}
user_workflows {
uuid id PK
uuid user_id FK
text workflow_name
text workflow_id
text service
text folder_path
timestamptz created_at
}
user ||--o| user_oauth_connections : has
user ||--o| n8n_credentials : has
user ||--o| user_workflows : has
Class diagram for new TypeScript user OAuth, n8n, and workflow typesclassDiagram
class UserOAuthConnection {
string id
string user_id
string provider
string service
string status
string scopes
}
class N8nCredential {
string id
string user_id
string n8n_credential_id
string service
}
class UserWorkflow {
string id
string user_id
string workflow_id
string workflow_name
string service
}
class User {
string user_id
}
User "1" --> "0..1" UserOAuthConnection : oauth_connection
User "1" --> "0..1" N8nCredential : n8n_credential
User "1" --> "0..1" UserWorkflow : workflow
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughWalkthroughAdds Gmail OAuth and n8n automation support: new DB tables and Hasura metadata, TypeScript types, n8n integration helpers, Hasura service helpers, and API routes to start/complete OAuth and enable/disable/execute Gmail automations; plus some Hasura relationship/permission tweaks and small auth change. Changes
Sequence Diagram(s)sequenceDiagram
participant Client as User/Client
participant Backend as App Backend
participant Google as Google OAuth
participant Hasura as Hasura
participant N8n as n8n
Client->>Backend: GET /api/oauth/google/start?userId=U
Backend-->>Client: Redirect to Google OAuth (state=U)
Client->>Google: Authorize (consent)
Google-->>Client: Redirect /callback?code=CODE&state=U
Client->>Backend: GET /api/oauth/google/callback?code=CODE&state=U
Backend->>Google: Exchange CODE for tokens
Google-->>Backend: tokens
Backend->>Hasura: insert user_oauth_connection (provider=google)
Hasura-->>Backend: persisted
Backend->>N8n: create credential (tokens)
N8n-->>Backend: n8n_credential_id
Backend->>Hasura: insert n8n_credentials record
Hasura-->>Backend: persisted
Backend->>N8n: duplicate template workflow (use new credential)
N8n-->>Backend: workflow_id + webhook_url
Backend->>Hasura: insert user_workflow (workflow_id, webhook_url)
Hasura-->>Backend: persisted
Backend-->>Client: Respond with webhook_url
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 5 issues, and left some high level feedback:
- The
public_preferenceuser role permissions were changed tocheck: {}andfilter: {}, which removes the per-useruser_idscoping—this effectively lets any user read/write any preference row; if that’s not intentional, please restore theuser_id = X-Hasura-User-Idchecks. - The new tables enforce
UNIQUE (user_id)(and inuser_workflowsalsoUNIQUE (created_at)), which will limit each user to a single workflow/connection and require globally unique timestamps; consider whether the intent is to allow multiple workflows/connections per user and, if so, relax these constraints. - In
user_oauth_connections,revoked_atisNOT NULLeven though status can beconnectedorrevoked; if active connections are expected to have no revoke time, consider makingrevoked_atnullable or enforcing consistency at the DB level (e.g., via check constraint).
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `public_preference` user role permissions were changed to `check: {}` and `filter: {}`, which removes the per-user `user_id` scoping—this effectively lets any user read/write any preference row; if that’s not intentional, please restore the `user_id = X-Hasura-User-Id` checks.
- The new tables enforce `UNIQUE (user_id)` (and in `user_workflows` also `UNIQUE (created_at)`), which will limit each user to a single workflow/connection and require globally unique timestamps; consider whether the intent is to allow multiple workflows/connections per user and, if so, relax these constraints.
- In `user_oauth_connections`, `revoked_at` is `NOT NULL` even though status can be `connected` or `revoked`; if active connections are expected to have no revoke time, consider making `revoked_at` nullable or enforcing consistency at the DB level (e.g., via check constraint).
## Individual Comments
### Comment 1
<location> `apps/hasura/metadata/databases/masterbots/tables/public_preference.yaml:36-42` </location>
<code_context>
- _eq: X-Hasura-User-Id
- set:
- user_id: X-Hasura-User-Id
+ check: {}
columns:
- deep_expertise
</code_context>
<issue_to_address>
**🚨 issue (security):** Removing the user_id-based row filter exposes all preferences across users to each other.
With `check: {}` (and no `set.user_id`), any authenticated `user` can now insert/select preference rows for any `user_id`, not just their own. If these are intended to remain per-user preferences, we should reinstate the row-level constraint tied to `X-Hasura-User-Id` or enforce equivalent restrictions elsewhere.
</issue_to_address>
### Comment 2
<location> `apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sql:1` </location>
<code_context>
+CREATE TABLE "public"."user_workflows" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "workflow_name" text NOT NULL, "workflow_id" text NOT NULL, "service" text NOT NULL, "folder_path" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("created_at"));
</code_context>
<issue_to_address>
**question (bug_risk):** The uniqueness constraints on `user_id` and `created_at` may be overly restrictive for workflows.
`UNIQUE ("user_id")` limits each user to a single row, which conflicts with the table name and presence of `workflow_id`/`workflow_name` (implying multiple workflows per user). `UNIQUE ("created_at")` is also a fragile global constraint on timestamps. If multiple workflows per user are intended, consider a composite key such as `UNIQUE ("user_id", "workflow_id")` or dropping these unique constraints entirely.
</issue_to_address>
### Comment 3
<location> `apps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sql:1` </location>
<code_context>
+CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"));
</code_context>
<issue_to_address>
**suggestion:** `revoked_at` being NOT NULL and a global UNIQUE on `user_id` may not align with typical OAuth connection lifecycles.
Two points to reconsider:
- `revoked_at` is `NOT NULL` while `status` can be `'connected'`, which forces a revocation time even for active connections. Allowing `revoked_at` to be NULL for active connections may better match the lifecycle.
- `UNIQUE ("user_id")` restricts each user to a single connection. If you expect multiple providers/services per user, a composite key like `UNIQUE ("user_id", "provider", "service")` would avoid that limitation.
If the invariant really is “exactly one connection per user with both timestamps always set”, consider adding a CHECK constraint tying `status` to the timestamp fields to make that explicit in the schema.
</issue_to_address>
### Comment 4
<location> `apps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sql:1` </location>
<code_context>
+CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id"));
</code_context>
<issue_to_address>
**question:** Uniqueness on `user_id` enforces a single n8n credential per user, which might be limiting.
This constraint allows only one `n8n_credentials` row per user. If users may need multiple credentials (e.g., per provider/service), consider a composite uniqueness such as `UNIQUE ("user_id", "provider", "service")` instead, unless a single global credential per user is explicitly required.
</issue_to_address>
### Comment 5
<location> `apps/web/types/types.ts:692-686` </location>
<code_context>
+}
+
+// n8n
+export interface N8nCredential {
+ id: string
+ user_id: string
+ n8n_credential_id: string
+ service: 'gmail'
+}
+
</code_context>
<issue_to_address>
**suggestion (bug_risk):** The N8nCredential interface doesn't reflect all DB fields and hardcodes `service` to 'gmail'.
The `n8n_credentials` table also has `provider`, free-text `service`, and `created_at`, but the interface only exposes a subset and restricts `service` to `'gmail'`. If this is intended to model the DB row, please add the missing fields and widen `service` (e.g., `string` or a union) to keep the type aligned with the stored data and avoid future drift.
Suggested implementation:
```typescript
// n8n
export interface N8nCredential {
id: string
user_id: string
n8n_credential_id: string
provider: string
service: string
created_at: string
}
// oauth
```
If your codebase represents timestamps as `Date` or a more specific time type instead of `string`, update the `created_at` field type accordingly (e.g., `created_at: Date`). Also ensure any existing usages of `N8nCredential` are updated to handle the new fields and the widened `service`/`provider` types.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| check: {} | ||
| columns: | ||
| - deep_expertise | ||
| - favorite | ||
| - font_size | ||
| - lang | ||
| - preferred_complexity | ||
| - preferred_length | ||
| - preferred_tone |
There was a problem hiding this comment.
🚨 issue (security): Removing the user_id-based row filter exposes all preferences across users to each other.
With check: {} (and no set.user_id), any authenticated user can now insert/select preference rows for any user_id, not just their own. If these are intended to remain per-user preferences, we should reinstate the row-level constraint tied to X-Hasura-User-Id or enforce equivalent restrictions elsewhere.
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."user_workflows" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "workflow_name" text NOT NULL, "workflow_id" text NOT NULL, "service" text NOT NULL, "folder_path" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("created_at")); | |||
There was a problem hiding this comment.
question (bug_risk): The uniqueness constraints on user_id and created_at may be overly restrictive for workflows.
UNIQUE ("user_id") limits each user to a single row, which conflicts with the table name and presence of workflow_id/workflow_name (implying multiple workflows per user). UNIQUE ("created_at") is also a fragile global constraint on timestamps. If multiple workflows per user are intended, consider a composite key such as UNIQUE ("user_id", "workflow_id") or dropping these unique constraints entirely.
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id")); | |||
There was a problem hiding this comment.
suggestion: revoked_at being NOT NULL and a global UNIQUE on user_id may not align with typical OAuth connection lifecycles.
Two points to reconsider:
revoked_atisNOT NULLwhilestatuscan be'connected', which forces a revocation time even for active connections. Allowingrevoked_atto be NULL for active connections may better match the lifecycle.UNIQUE ("user_id")restricts each user to a single connection. If you expect multiple providers/services per user, a composite key likeUNIQUE ("user_id", "provider", "service")would avoid that limitation.
If the invariant really is “exactly one connection per user with both timestamps always set”, consider adding a CHECK constraint tyingstatusto the timestamp fields to make that explicit in the schema.
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id")); | |||
There was a problem hiding this comment.
question: Uniqueness on user_id enforces a single n8n credential per user, which might be limiting.
This constraint allows only one n8n_credentials row per user. If users may need multiple credentials (e.g., per provider/service), consider a composite uniqueness such as UNIQUE ("user_id", "provider", "service") instead, unless a single global credential per user is explicitly required.
| id: string | ||
| user_id: string | ||
| provider: 'google' | ||
| service: 'gmail' |
There was a problem hiding this comment.
suggestion (bug_risk): The N8nCredential interface doesn't reflect all DB fields and hardcodes service to 'gmail'.
The n8n_credentials table also has provider, free-text service, and created_at, but the interface only exposes a subset and restricts service to 'gmail'. If this is intended to model the DB row, please add the missing fields and widen service (e.g., string or a union) to keep the type aligned with the stored data and avoid future drift.
Suggested implementation:
// n8n
export interface N8nCredential {
id: string
user_id: string
n8n_credential_id: string
provider: string
service: string
created_at: string
}
// oauthIf your codebase represents timestamps as Date or a more specific time type instead of string, update the created_at field type accordingly (e.g., created_at: Date). Also ensure any existing usages of N8nCredential are updated to handle the new fields and the widened service/provider types.
There was a problem hiding this comment.
Pull request overview
This work-in-progress PR introduces database schema and infrastructure for N8N workflow automation integration, enabling users to create and manage automated workflows with OAuth-based service connections. The changes include adding three new tables for workflows, OAuth connections, and N8N credentials, while removing deprecated organization and department structures.
Key Changes:
- Added N8N integration infrastructure with new database tables for user workflows, OAuth connections, and credentials
- Removed deprecated organization and department tables and associated GraphQL types
- Modified Hasura permissions for preference and thread tables
Reviewed changes
Copilot reviewed 14 out of 23 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/mb-genql/generated/schema.ts | Auto-generated GraphQL types reflecting new N8N tables and removal of organization/department entities |
| apps/web/types/types.ts | TypeScript type definitions for OAuth connections, N8N credentials, and user workflows |
| apps/hasura/migrations/.../user_workflows/up.sql | Migration creating user_workflows table with problematic unique constraints |
| apps/hasura/migrations/.../user_oauth_connections/up.sql | Migration creating OAuth connections table with overly restrictive user_id constraint |
| apps/hasura/migrations/.../n8n_credentials/up.sql | Migration creating N8N credentials table with limiting user_id constraint |
| apps/hasura/metadata/.../tables.yaml | Updated table registry removing old tables and adding new N8N-related tables |
| apps/hasura/metadata/.../public_preference.yaml | Modified permissions removing user isolation checks (security issue) |
| apps/hasura/metadata/.../public_chatbot.yaml | Column reordering and duplicate chatbot_id entry |
| apps/hasura/metadata/.../public_thread.yaml | Removed metadata column from insert permissions |
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."user_workflows" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "workflow_name" text NOT NULL, "workflow_id" text NOT NULL, "service" text NOT NULL, "folder_path" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("created_at")); | |||
There was a problem hiding this comment.
The unique constraint on user_id means each user can only have one workflow, which seems overly restrictive for a workflows table. Users typically need to create multiple workflows. This should either be removed or changed to a composite unique constraint like UNIQUE (user_id, workflow_id) if you want to prevent duplicate workflow associations.
| CREATE TABLE "public"."user_workflows" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "workflow_name" text NOT NULL, "workflow_id" text NOT NULL, "service" text NOT NULL, "folder_path" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("created_at")); | |
| CREATE TABLE "public"."user_workflows" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "workflow_name" text NOT NULL, "workflow_id" text NOT NULL, "service" text NOT NULL, "folder_path" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id", "workflow_id"), UNIQUE ("created_at")); |
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id")); | |||
There was a problem hiding this comment.
The unique constraint on user_id restricts each user to a single N8N credential across all services, which is too restrictive. Users may need separate credentials for different services (Gmail, Slack, etc.). Consider using a composite unique constraint like UNIQUE (user_id, service) or UNIQUE (user_id, provider, service) instead.
| CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id")); | |
| CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id", "provider", "service"), UNIQUE ("n8n_credential_id")); |
| filter: | ||
| user_id: | ||
| _eq: X-Hasura-User-Id | ||
| filter: {} |
There was a problem hiding this comment.
The filter: {} permission allows any authenticated user to read all preferences from all users, which is a privacy violation. The original permission with user_id filter should be restored to ensure users can only access their own preferences.
| filter: {} | |
| filter: | |
| user_id: | |
| _eq: X-Hasura-User-Id |
| user_id: string | ||
| provider: 'google' | ||
| service: 'gmail' | ||
| status: 'connected' | 'revoked' | ||
| scopes: string | ||
| } | ||
|
|
||
| // n8n | ||
| export interface N8nCredential { | ||
| id: string | ||
| user_id: string | ||
| n8n_credential_id: string | ||
| service: 'gmail' | ||
| } | ||
|
|
||
| // workflow | ||
| export interface UserWorkflow { | ||
| id: string | ||
| user_id: string | ||
| workflow_id: string | ||
| workflow_name: string | ||
| service: 'gmail' |
There was a problem hiding this comment.
Naming inconsistency: TypeScript interface uses user_id and n8n_credential_id (snake_case) but the GraphQL schema uses userId and n8nCredentialId (camelCase). TypeScript types should follow the GraphQL naming convention for consistency with the auto-generated types.
| user_id: string | |
| provider: 'google' | |
| service: 'gmail' | |
| status: 'connected' | 'revoked' | |
| scopes: string | |
| } | |
| // n8n | |
| export interface N8nCredential { | |
| id: string | |
| user_id: string | |
| n8n_credential_id: string | |
| service: 'gmail' | |
| } | |
| // workflow | |
| export interface UserWorkflow { | |
| id: string | |
| user_id: string | |
| workflow_id: string | |
| workflow_name: string | |
| service: 'gmail' | |
| userId: string | |
| provider: 'google' | |
| service: 'gmail' | |
| status: 'connected' | 'revoked' | |
| scopes: string | |
| /** | |
| * @deprecated Use `userId` instead. Kept for backward compatibility. | |
| */ | |
| user_id?: string | |
| } | |
| // n8n | |
| export interface N8nCredential { | |
| id: string | |
| userId: string | |
| n8nCredentialId: string | |
| service: 'gmail' | |
| /** | |
| * @deprecated Use `userId` instead. Kept for backward compatibility. | |
| */ | |
| user_id?: string | |
| /** | |
| * @deprecated Use `n8nCredentialId` instead. Kept for backward compatibility. | |
| */ | |
| n8n_credential_id?: string | |
| } | |
| // workflow | |
| export interface UserWorkflow { | |
| id: string | |
| userId: string | |
| workflowId: string | |
| workflowName: string | |
| service: 'gmail' | |
| /** | |
| * @deprecated Use `userId` instead. Kept for backward compatibility. | |
| */ | |
| user_id?: string | |
| /** | |
| * @deprecated Use `workflowId` instead. Kept for backward compatibility. | |
| */ | |
| workflow_id?: string | |
| /** | |
| * @deprecated Use `workflowName` instead. Kept for backward compatibility. | |
| */ | |
| workflow_name?: string |
| export interface UserWorkflow { | ||
| id: string | ||
| user_id: string | ||
| workflow_id: string | ||
| workflow_name: string | ||
| service: 'gmail' | ||
| } |
There was a problem hiding this comment.
Naming inconsistency: TypeScript interface uses user_id, workflow_id, and workflow_name (snake_case) but the GraphQL schema uses userId, workflowId, and workflowName (camelCase). TypeScript types should follow the GraphQL naming convention for consistency with the auto-generated types.
| columns: | ||
| - avatar | ||
| - chatbot_id | ||
| - chatbot_id |
There was a problem hiding this comment.
Duplicate column chatbot_id appears twice in the select permissions. This appears to be an accidental duplication that should be removed.
| - chatbot_id |
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."user_workflows" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "workflow_name" text NOT NULL, "workflow_id" text NOT NULL, "service" text NOT NULL, "folder_path" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("created_at")); | |||
There was a problem hiding this comment.
The unique constraint on created_at in the user_workflows table is problematic. Using a timestamp as a unique constraint can cause insertion failures if multiple workflows are created at the same time (which is possible within the same millisecond). Consider removing this constraint or using a composite unique constraint if you need to prevent duplicate workflows per user.
| CREATE TABLE "public"."user_workflows" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "workflow_name" text NOT NULL, "workflow_id" text NOT NULL, "service" text NOT NULL, "folder_path" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("created_at")); | |
| CREATE TABLE "public"."user_workflows" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "workflow_name" text NOT NULL, "workflow_id" text NOT NULL, "service" text NOT NULL, "folder_path" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id")); |
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id")); | |||
There was a problem hiding this comment.
The unique constraint on user_id means each user can only have one OAuth connection, which limits the system to a single provider/service per user. If users should be able to connect multiple services (e.g., Gmail and Google Drive), consider using a composite unique constraint like UNIQUE (user_id, provider, service) instead.
| CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id")); | |
| CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id", "provider", "service"))); |
| _eq: X-Hasura-User-Id | ||
| set: | ||
| user_id: X-Hasura-User-Id | ||
| check: {} |
There was a problem hiding this comment.
The check: {} permission allows any authenticated user to insert preferences for any user, bypassing user isolation. This is a security vulnerability. The original permission with user_id check should be restored to ensure users can only create their own preferences.
| check: {} | |
| check: | |
| user_id: | |
| _eq: X-Hasura-User-Id |
| export interface UserOAuthConnection { | ||
| id: string | ||
| user_id: string | ||
| provider: 'google' | ||
| service: 'gmail' | ||
| status: 'connected' | 'revoked' | ||
| scopes: string | ||
| } |
There was a problem hiding this comment.
Naming inconsistency: TypeScript interface uses user_id (snake_case) but the GraphQL schema uses userId (camelCase). TypeScript types should follow the GraphQL naming convention (camelCase) for consistency with the auto-generated types from mb-genql.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/hasura/metadata/databases/masterbots/tables/public_chatbot.yaml (2)
42-42: Fix the typo in the column name.The prompts relationship references
chabot_id(missing 't'), but the correct column name should bechatbot_id. This typo will break the foreign key relationship and cause GraphQL queries for prompts to fail.🔎 Proposed fix
- column: chabot_id + column: chatbot_id
4-16: Fix broken department relationship references throughout the codebase.The department object relationship and organization_chatbots array relationship have been removed from the public_chatbot.yaml metadata, but the application code in apps/pro-web still has extensive active dependencies on the department relationship:
getDepartments(),getDepartment()service callsactiveDepartmentstate management in sidebar/contextchatbot.department?.namereferences in components- Department-based filtering and categorization logic
These references will break at runtime since the relationship is no longer exposed via GraphQL. Update or remove all references to
chatbot.departmentthroughout the codebase, or restore the department relationship to the metadata.
🧹 Nitpick comments (7)
apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/down.sql (1)
1-1: Consider adding IF EXISTS and CASCADE for robustness.The down migration could be more robust by:
- Adding
IF EXISTSto make the migration idempotent- Considering
CASCADEif there might be dependent objects (views, triggers, etc.)🔎 Proposed enhancement
-DROP TABLE "public"."user_workflows"; +DROP TABLE IF EXISTS "public"."user_workflows" CASCADE;Note: Only add
CASCADEif you're certain there are no dependent objects you want to preserve, or if dropping them is the intended behavior.apps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/down.sql (1)
1-1: Consider adding IF EXISTS and CASCADE for robustness.The down migration could be more robust and idempotent.
🔎 Proposed enhancement
-DROP TABLE "public"."user_oauth_connections"; +DROP TABLE IF EXISTS "public"."user_oauth_connections" CASCADE;Note: Only add
CASCADEif dropping dependent objects is the intended behavior.apps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/down.sql (1)
1-1: Consider adding IF EXISTS and CASCADE for robustness.The down migration could be more robust and idempotent.
🔎 Proposed enhancement
-DROP TABLE "public"."n8n_credentials"; +DROP TABLE IF EXISTS "public"."n8n_credentials" CASCADE;Note: Only add
CASCADEif dropping dependent objects is the intended behavior.apps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sql (2)
1-1: Remove redundant UNIQUE constraint on primary key.The
UNIQUE ("id")constraint is redundant sinceidis already thePRIMARY KEY, which implicitly enforces uniqueness.🔎 Proposed cleanup
-CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id")); +CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("user_id"), UNIQUE ("n8n_credential_id"));
1-1: Consider CASCADE delete behavior for user credentials.The foreign key uses
ON DELETE restrict, which prevents user deletion if credentials exist. Consider usingON DELETE cascadeto automatically clean up credentials when a user is deleted, unless you have a specific requirement to preserve orphaned credentials.apps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sql (1)
1-1: Consider enum type or check constraint for status.The
statuscolumn is free-form text, which can lead to inconsistent values. Consider using a PostgreSQL enum type or a CHECK constraint to ensure only valid status values ('connected', 'revoked') are allowed.🔎 Example with enum type
CREATE TYPE oauth_status AS ENUM ('connected', 'revoked'); CREATE TABLE "public"."user_oauth_connections" ( "id" uuid NOT NULL DEFAULT gen_random_uuid(), "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" oauth_status NOT NULL DEFAULT 'connected', "connected_at" timestamptz NOT NULL DEFAULT now(), "revoked_at" timestamptz, PRIMARY KEY ("id"), FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE cascade, UNIQUE ("user_id", "provider", "service") );apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sql (1)
1-1: Consider indexes for common query patterns.Add indexes to optimize common queries by user, service, or workflow_id:
CREATE INDEX idx_user_workflows_user_id ON public.user_workflows(user_id); CREATE INDEX idx_user_workflows_service ON public.user_workflows(service); CREATE INDEX idx_user_workflows_workflow_id ON public.user_workflows(workflow_id);
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
packages/mb-genql/generated/schema.graphqlis excluded by!**/generated/**packages/mb-genql/generated/schema.tsis excluded by!**/generated/**packages/mb-genql/generated/types.tsis excluded by!**/generated/**
📒 Files selected for processing (20)
apps/hasura/metadata/databases/masterbots/tables/public_chatbot.yamlapps/hasura/metadata/databases/masterbots/tables/public_n8n_credentials.yamlapps/hasura/metadata/databases/masterbots/tables/public_preference.yamlapps/hasura/metadata/databases/masterbots/tables/public_thread.yamlapps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yamlapps/hasura/metadata/databases/masterbots/tables/public_user_workflows.yamlapps/hasura/metadata/databases/masterbots/tables/tables.yamlapps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/down.sqlapps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sqlapps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/down.sqlapps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/down.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sqlapps/web/app/api/automations/gmail/disable.tsapps/web/app/api/automations/gmail/enable.tsapps/web/app/api/automations/gmail/execute.tsapps/web/app/api/oauth/google/callback.tsapps/web/app/api/oauth/google/revoke.tsapps/web/app/api/oauth/google/start.tsapps/web/types/types.ts
💤 Files with no reviewable changes (1)
- apps/hasura/metadata/databases/masterbots/tables/public_thread.yaml
🧰 Additional context used
📓 Path-based instructions (6)
apps/hasura/migrations/masterbots/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Store and manage Hasura migrations under apps/hasura/migrations/masterbots/
Store Hasura-managed migrations in timestamped folders under apps/hasura/migrations/masterbots/
Keep Hasura-managed database migrations in timestamped folders under apps/hasura/migrations/masterbots/
Files:
apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/down.sqlapps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/down.sqlapps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sqlapps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/down.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sql
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: Use lowercase with dash-separated directory and file names; use specific extensions: .config.ts, .test.ts, .context.tsx, .type.ts, .hook.ts; components may omit extension
Use Bun for package management and scripts instead of npm/yarn
Use Biome for formatting and linting via bun format-and-lint:fix; avoid Prettier/ESLint configs
Files:
apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/down.sqlapps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sqlapps/hasura/metadata/databases/masterbots/tables/public_user_workflows.yamlapps/hasura/metadata/databases/masterbots/tables/tables.yamlapps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yamlapps/web/types/types.tsapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/down.sqlapps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sqlapps/hasura/metadata/databases/masterbots/tables/public_n8n_credentials.yamlapps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/down.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sqlapps/hasura/metadata/databases/masterbots/tables/public_chatbot.yamlapps/hasura/metadata/databases/masterbots/tables/public_preference.yaml
apps/{web,pro-web}/types/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Place shared TypeScript definitions under types/
Keep TypeScript type definitions under types/
Files:
apps/web/types/types.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Use meaningful variable names; prefix booleans with is/has/does/should
Use interface for objects/classes; type for unions/tuples/aliases; enum for fixed sets; const for literals
Avoid any; prefer specific types
Leverage type inference where clear; annotate function params and return types
Prefer type assertions with 'as' over angle-bracket syntax
Use type guards to narrow types in conditionals
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Use modern JavaScript features with TypeScript across the codebase
Use meaningful names; prefix booleans with is/has/does/should (e.g., isDisabled)
Receive an object and return an object (RORO) for functions interfacing with external services
Type definitions: use interface for objects/classes; type for unions/tuples/aliases; const for literals; enum for fixed sets
Avoid any; prefer specific types
Leverage type inference; omit explicit annotations when obvious
Add explicit type annotations for function parameters and return values
Prefer type assertions with as over angle-bracket syntax
Use type guards to narrow types within conditionals
Favor composition over inheritance in code structure
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Prefer RORO (Receive an object, return an object) for function signatures, especially for external service interactions
Use interface for object shapes/classes; type for unions/tuples/aliases; const for literals; enum for fixed enumerations
Avoid using any; prefer precise types
Leverage type inference when clear; omit redundant annotations
Explicitly annotate function parameters and return types
Prefer type assertions with as over angle-bracket syntax
Use type guards to narrow types safely
Use meaningful variable names; prefix booleans with is/has/does/should
Favor composition over inheritance
Use lowercase dash-separated names for files and folders; use extensions like .config.ts, .test.ts, .context.tsx, .typ...
Files:
apps/web/types/types.ts
apps/{web,pro-web}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
apps/{web,pro-web}/**/*.{ts,tsx}: Use lowercase kebab-case for directories and filenames (components can omit extension)
Verify DOM operations and consider timing (RAF/delays) when manipulating the DOM in React
Use Tailwind CSS utility classes for styling React components
apps/{web,pro-web}/**/*.{ts,tsx}: Use TypeScript to define React props types (interfaces for props)
Use custom hooks (useMBChat, useThread, useSidebar, useModel) for domain-specific state and keep providers focused and composed hierarchically
Separate presentation from business logic and compose small components
Use hasura.service.ts for all GraphQL operations from UI layers
apps/{web,pro-web}/**/*.{ts,tsx}: Prefer Server Components; use the use client directive only when client-side features are required
Implement Nested Layouts using the App Router
Use Streaming and Suspense in Next.js 14/15 where appropriate
Follow Next.js file conventions as per documentation
Use IndexedDB for local caching to enable immediate UI updates
Files:
apps/web/types/types.ts
apps/{web,pro-web}/types/**/*.ts
📄 CodeRabbit inference engine (AGENTS.md)
Place shared TypeScript types under types/
Files:
apps/web/types/types.ts
🧠 Learnings (7)
📓 Common learnings
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 0
File: :0-0
Timestamp: 2024-12-05T01:08:50.085Z
Learning: The backend uses Hasura with proper table relationships, permissions, and metadata structure defined in YAML configurations.
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Perform database schema changes via Hasura console (task console), then migrations (task migrate)
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Use Hasura console (task console) for schema modifications
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 0
File: :0-0
Timestamp: 2024-12-05T01:08:50.085Z
Learning: The project is a monorepo using Turborepo with Next.js frontend (apps/masterbots.ai), Hasura backend (apps/hasura), and shared packages for types, GraphQL operations, and utilities.
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 344
File: apps/masterbots.ai/services/hasura/hasura.service.ts:0-0
Timestamp: 2025-01-25T08:43:05.202Z
Learning: In the masterbots.ai database schema:
1. Previous "categories" are now called "topics"
2. Chatbots are now referred to as "domains"
3. Domains have context-dependent "categories" and "subcategories" based on user question context
4. Domains include "tags" that are used for filtering based on the user question context
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 579
File: apps/pro-web/app/api/auth/signup/route.ts:151-157
Timestamp: 2025-11-07T18:38:42.273Z
Learning: In apps/pro-web/app/actions/admin.actions.ts, the insertUserOrganizations function should use Drizzle DB transactions to ensure atomicity when inserting organizations and their associated chatbots, preventing partial persistence issues.
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to apps/hasura/migrations/masterbots/** : Keep Hasura-managed database migrations in timestamped folders under apps/hasura/migrations/masterbots/
Applied to files:
apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/down.sqlapps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/down.sqlapps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sql
📚 Learning: 2025-09-30T22:08:30.965Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-09-30T22:08:30.965Z
Learning: Applies to apps/hasura/migrations/masterbots/** : Store and manage Hasura migrations under apps/hasura/migrations/masterbots/
Applied to files:
apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/down.sqlapps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/down.sqlapps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sqlapps/hasura/metadata/databases/masterbots/tables/public_n8n_credentials.yamlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sql
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Applies to apps/hasura/migrations/masterbots/** : Store Hasura-managed migrations in timestamped folders under apps/hasura/migrations/masterbots/
Applied to files:
apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/down.sqlapps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sqlapps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sql
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Perform database schema changes via Hasura console (task console), then migrations (task migrate)
Applied to files:
apps/hasura/migrations/masterbots/1766065373919_create_table_public_user_workflows/up.sql
📚 Learning: 2025-11-06T22:31:20.903Z
Learnt from: derianrddev
Repo: bitcashorg/masterbots PR: 579
File: apps/hasura/migrations/masterbots/1762286346002_alter_table_public_chatbot_add_column_department_id/up.sql:1-2
Timestamp: 2025-11-06T22:31:20.903Z
Learning: In the masterbots codebase, the `department_id` column in the `public.chatbot` table is intentionally nullable because not all chatbots are part of the onboarding flow. Only chatbots used in onboarding have an associated department.
Applied to files:
apps/hasura/metadata/databases/masterbots/tables/public_chatbot.yaml
📚 Learning: 2025-01-25T08:43:05.202Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 344
File: apps/masterbots.ai/services/hasura/hasura.service.ts:0-0
Timestamp: 2025-01-25T08:43:05.202Z
Learning: In the masterbots.ai database schema:
1. Previous "categories" are now called "topics"
2. Chatbots are now referred to as "domains"
3. Domains have context-dependent "categories" and "subcategories" based on user question context
4. Domains include "tags" that are used for filtering based on the user question context
Applied to files:
apps/hasura/metadata/databases/masterbots/tables/public_chatbot.yaml
🔇 Additional comments (2)
apps/hasura/metadata/databases/masterbots/tables/tables.yaml (2)
14-14: LGTM! New table metadata files properly included.The three new table metadata files are correctly included in alphabetical order:
public_n8n_credentials.yaml(line 14)public_user_oauth_connections.yaml(line 29)public_user_workflows.yaml(line 31)Also applies to: 29-29, 31-31
1-31: The metadata files (public_department.yaml,public_organization.yaml,public_organization_chatbot.yaml) have not been removed. All three files continue to exist in the metadata directory. Additionally, proper down migrations exist for each table:
1762284507301_create_table_public_department/down.sql- drops the department table1761768880712_create_table_public_organization/down.sql- drops the organization table1762287961522_create_table_public_organization_chatbot/down.sql- drops the organization_chatbot tableThe database schema is consistent with the migration history.
Likely an incorrect or invalid review comment.
| columns: | ||
| - avatar | ||
| - chatbot_id | ||
| - chatbot_id |
There was a problem hiding this comment.
Remove duplicate column entry.
The chatbot_id column appears twice in the anonymous role's select permissions (lines 58 and 59). This duplication is redundant and may cause metadata validation warnings.
🔎 Proposed fix
columns:
- avatar
- chatbot_id
- - chatbot_id
- created_by📝 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.
| - chatbot_id | |
| columns: | |
| - avatar | |
| - chatbot_id | |
| - created_by |
🤖 Prompt for AI Agents
In apps/hasura/metadata/databases/masterbots/tables/public_chatbot.yaml around
line 59, the anonymous role's select permissions include a duplicated
"chatbot_id" column entry; remove the second occurrence (the entry on line 59)
so each column appears only once in the columns list, then save and run Hasura
metadata validation to ensure no warnings remain.
| table: | ||
| name: n8n_credentials | ||
| schema: public |
There was a problem hiding this comment.
Critical: Add strict permissions for credential data.
This table stores n8n credentials, which are highly sensitive. This MUST have proper permissions before merging to any non-development environment:
- Strict row-level security: Users should ONLY access their own credentials
- Object relationship to
public.uservia theuser_idforeign key - Limited column access: Consider whether all credential fields should be readable
- Audit logging: Consider tracking access to credential data
🔎 Example with strict security controls
table:
name: n8n_credentials
schema: public
object_relationships:
- name: user
using:
foreign_key_constraint_on: user_id
select_permissions:
- role: user
permission:
columns:
- id
- user_id
- provider
- service
- n8n_credential_id
- created_at
filter:
user_id:
_eq: X-Hasura-User-Id
insert_permissions:
- role: user
permission:
check:
user_id:
_eq: X-Hasura-User-Id
columns:
- provider
- service
- n8n_credential_id
delete_permissions:
- role: user
permission:
filter:
user_id:
_eq: X-Hasura-User-Id🤖 Prompt for AI Agents
In apps/hasura/metadata/databases/masterbots/tables/public_n8n_credentials.yaml
lines 1-3: this table holds sensitive n8n credentials and needs strict security
before non-dev deployment—enable row-level security, add an object_relationship
named "user" using foreign_key_constraint_on: user_id, and add
select/insert/delete permissions scoped to role "user" that filter/check user_id
equals X-Hasura-User-Id; restrict select columns to only non-secret fields
(e.g., id, user_id, provider, service, n8n_credential_id, created_at), restrict
insert columns to only allowed writable fields, and restrict delete to the same
user filter; additionally ensure any remaining secret columns are excluded from
select and consider adding audit logging/triggers for access events.
| _eq: X-Hasura-User-Id | ||
| set: | ||
| user_id: X-Hasura-User-Id | ||
| check: {} |
There was a problem hiding this comment.
Critical security vulnerability: Empty check allows privilege escalation.
The empty check: {} for the user role permits any authenticated user to insert preferences with any user_id, effectively allowing users to create or modify preferences for other users.
This should enforce row-level security:
check:
user_id:
_eq: X-Hasura-User-Id🔎 Proposed fix
- role: user
permission:
- check: {}
+ check:
+ user_id:
+ _eq: X-Hasura-User-Id
columns:🤖 Prompt for AI Agents
In apps/hasura/metadata/databases/masterbots/tables/public_preference.yaml
around line 36, the `check: {}` for the `user` role allows any authenticated
user to insert or modify rows for arbitrary `user_id`; replace the empty check
with a row-level security condition that enforces user_id equals the Hasura
session variable (X-Hasura-User-Id) for inserts/updates (e.g. set check to
require user_id _eq to the X-Hasura-User-Id session variable), ensuring the
comparison type matches the column type (cast the session var if needed) and
keep the rest of the permission block intact.
| filter: | ||
| user_id: | ||
| _eq: X-Hasura-User-Id | ||
| filter: {} |
There was a problem hiding this comment.
Critical security vulnerability: Empty filter exposes all user preferences.
The empty filter: {} for the user role allows any authenticated user to query all preferences across all users, leaking sensitive user data.
This should enforce row-level security to restrict users to their own preferences.
🔎 Proposed fix
- role: user
permission:
columns:
- deep_expertise
- favorite
- font_size
- lang
- preference_id
- preferred_complexity
- preferred_length
- preferred_tone
- preferred_type
- user_id
- web_search
- filter: {}
+ filter:
+ user_id:
+ _eq: X-Hasura-User-Id
comment: ""🤖 Prompt for AI Agents
In apps/hasura/metadata/databases/masterbots/tables/public_preference.yaml
around line 94, the permission filter is currently empty (filter: {}), exposing
all preferences; replace it with a row-level filter that restricts results to
the logged-in user by comparing the preference's user_id to the Hasura session
variable (for example: set filter to {"user_id": {"_eq": "X-Hasura-User-Id"}} or
to the correct JWT claim/key your app uses, e.g. "x-hasura-user-id"), ensuring
the permission only returns rows where user_id equals the session user id.
| table: | ||
| name: user_oauth_connections | ||
| schema: public |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add permissions and relationships with privacy controls.
This table stores OAuth connection data, which is sensitive user information. Before merging, you should add:
- Row-level security: Users should only access their own OAuth connections
- Object relationship to
public.uservia theuser_idforeign key - Restricted permissions: Carefully control which roles can select/insert/update/delete
🔎 Example with privacy controls
table:
name: user_oauth_connections
schema: public
object_relationships:
- name: user
using:
foreign_key_constraint_on: user_id
select_permissions:
- role: user
permission:
columns:
- id
- user_id
- provider
- service
- scopes
- status
- connected_at
- revoked_at
filter:
user_id:
_eq: X-Hasura-User-Id
insert_permissions:
- role: user
permission:
check:
user_id:
_eq: X-Hasura-User-Id
columns:
- provider
- service
- scopes
- status
update_permissions:
- role: user
permission:
columns:
- status
- revoked_at
filter:
user_id:
_eq: X-Hasura-User-Id🤖 Prompt for AI Agents
In
apps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yaml
around lines 1-3, the table currently lacks row-level security, object
relationship to public.user, and role-restricted permissions; add an
object_relationship mapping on user_id to public.user, enable/select row-level
security policies so users can only access their own rows (filters using
X-Hasura-User-Id), and add select/insert/update (and delete if needed)
permission entries for the user role that explicitly list allowed columns, use
filters like user_id: {_eq: X-Hasura-User-Id} for selects/updates and checks for
inserts, and restrict update columns to only safe fields (e.g., status,
revoked_at) while preventing exposing sensitive columns.
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id")); | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add timestamp defaults and updated_at column.
The connected_at column lacks a default value. Additionally, tracking when connection details (like scopes or status) change requires an updated_at column.
🔎 Proposed improvements
-CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"));
+CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL DEFAULT gen_random_uuid(), "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL DEFAULT now(), "revoked_at" timestamptz, "updated_at" timestamptz NOT NULL DEFAULT now(), PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"));🤖 Prompt for AI Agents
In
apps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sql
around line 1, the connected_at column has no default and there's no updated_at
column; alter the CREATE TABLE to set connected_at timestamptz NOT NULL DEFAULT
now() and add updated_at timestamptz NOT NULL DEFAULT now(); optionally add a DB
trigger or application logic to set updated_at on row updates if you want
automatic updates (but at minimum add the column with a default).
Critical constraint: UNIQUE user_id prevents multiple OAuth connections.
The UNIQUE ("user_id") constraint allows only one OAuth connection per user across all providers and services. This is severely limiting—users cannot connect both Google and another provider, or even multiple Google services.
This should likely be a composite unique constraint on (user_id, provider, service) to allow multiple connections:
🔎 Proposed fix
-CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"));
+CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL DEFAULT gen_random_uuid(), "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL DEFAULT now(), "revoked_at" timestamptz, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE cascade, UNIQUE ("user_id", "provider", "service"));📝 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 TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id")); | |
| CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL DEFAULT gen_random_uuid(), "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL DEFAULT now(), "revoked_at" timestamptz, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE cascade, UNIQUE ("user_id", "provider", "service")); |
🤖 Prompt for AI Agents
In
apps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sql
around line 1, the migration defines UNIQUE("user_id") which wrongly prevents a
user from having multiple OAuth connections; remove that single-column unique
constraint and replace it with a composite unique constraint on (user_id,
provider, service) so a user can have multiple provider/service connections but
still avoid duplicate entries for the same provider+service combination.
Incorrect nullability: revoked_at should be nullable.
The revoked_at column is defined as NOT NULL, but it should only be populated when a connection is revoked. For active connections, this field should be NULL.
This forces inserting a placeholder value (like a distant past/future date) for active connections, which is an anti-pattern.
🔎 Proposed fix
-CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"));
+CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL DEFAULT now(), "revoked_at" timestamptz, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"));📝 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 TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL, "revoked_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id")); | |
| CREATE TABLE "public"."user_oauth_connections" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "scopes" text NOT NULL, "status" text NOT NULL, "connected_at" timestamptz NOT NULL DEFAULT now(), "revoked_at" timestamptz, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id")); |
🤖 Prompt for AI Agents
In
apps/hasura/migrations/masterbots/1766066591567_create_table_public_user_oauth_connections/up.sql
around line 1, the revoked_at column is declared as NOT NULL but should be
nullable; update the CREATE TABLE statement to remove the NOT NULL from
revoked_at so it becomes nullable, and if applying to an existing DB include a
migration step to ALTER TABLE ... ALTER COLUMN revoked_at DROP NOT NULL and
ensure any existing placeholder values are corrected to NULL as appropriate.
| @@ -0,0 +1 @@ | |||
| CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id")); | |||
There was a problem hiding this comment.
UNIQUE constraint on user_id limits users to one n8n credential.
The UNIQUE ("user_id") constraint prevents users from having multiple n8n credentials. This is overly restrictive if users need credentials for multiple services or multiple credentials for the same service.
Consider removing this constraint or making it a composite unique key with service if you want to allow one credential per service per user:
UNIQUE ("user_id", "service")🔎 Proposed fix
-CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id"));
+CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL DEFAULT now(), "updated_at" timestamptz NOT NULL DEFAULT now(), PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE cascade, UNIQUE ("n8n_credential_id"), UNIQUE ("user_id", "service"));🤖 Prompt for AI Agents
In
apps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sql
around line 1, the current UNIQUE("user_id") constraint prevents a user from
having multiple n8n credentials; remove the standalone UNIQUE("user_id") or
replace it with a composite unique constraint such as
UNIQUE("user_id","service") to allow multiple credentials per user while still
enforcing one credential per service per user; update the CREATE TABLE statement
to drop the single-column unique and add the composite unique (or omit
uniqueness entirely) and ensure any downstream references or migrations are
adjusted accordingly.
🛠️ Refactor suggestion | 🟠 Major
Add default timestamp and updated_at column.
The created_at column lacks a default value, requiring manual timestamp insertion on every insert. Additionally, there's no updated_at column to track modifications.
🔎 Proposed improvements
-CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id"));
+CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL DEFAULT gen_random_uuid(), "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL DEFAULT now(), "updated_at" timestamptz NOT NULL DEFAULT now(), PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("user_id"), UNIQUE ("n8n_credential_id"));Also consider adding a trigger to automatically update updated_at:
CREATE TRIGGER set_updated_at
BEFORE UPDATE ON public.n8n_credentials
FOR EACH ROW
EXECUTE FUNCTION public.set_current_timestamp_updated_at();📝 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 TABLE "public"."n8n_credentials" ("id" uuid NOT NULL, "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL, PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("id"), UNIQUE ("user_id"), UNIQUE ("n8n_credential_id")); | |
| CREATE TABLE "public"."n8n_credentials" ("id" uuid NOT NULL DEFAULT gen_random_uuid(), "user_id" uuid NOT NULL, "provider" text NOT NULL, "service" text NOT NULL, "n8n_credential_id" text NOT NULL, "created_at" timestamptz NOT NULL DEFAULT now(), "updated_at" timestamptz NOT NULL DEFAULT now(), PRIMARY KEY ("id") , FOREIGN KEY ("user_id") REFERENCES "public"."user"("user_id") ON UPDATE restrict ON DELETE restrict, UNIQUE ("user_id"), UNIQUE ("n8n_credential_id")); |
🤖 Prompt for AI Agents
In
apps/hasura/migrations/masterbots/1766066981705_create_table_public_n8n_credentials/up.sql
around line 1, the CREATE TABLE lacks a default for created_at and omits an
updated_at column; modify the table definition so created_at has a default of
now() and add an updated_at timestamptz column also defaulting to now() (both
NOT NULL), and after the table creation add a trigger (or trigger creation
statement) to set updated_at on each UPDATE using the existing
public.set_current_timestamp_updated_at() function (or create that function if
missing).
| export interface UserOAuthConnection { | ||
| id: string | ||
| user_id: string | ||
| provider: 'google' | ||
| service: 'gmail' | ||
| status: 'connected' | 'revoked' | ||
| scopes: string | ||
| } |
There was a problem hiding this comment.
Schema mismatch: Missing timestamp fields from database.
The UserOAuthConnection interface is missing connected_at, revoked_at, and potentially updated_at fields that exist in the database schema (see migration file). This mismatch will cause runtime errors when querying these fields from Hasura.
Additionally, revoked_at should be optional (revoked_at?: string) since it's nullable in the database.
🔎 Proposed fix to align with database schema
export interface UserOAuthConnection {
id: string
user_id: string
provider: 'google'
service: 'gmail'
status: 'connected' | 'revoked'
scopes: string
+ connected_at: string
+ revoked_at?: string
+ updated_at?: string
}📝 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.
| export interface UserOAuthConnection { | |
| id: string | |
| user_id: string | |
| provider: 'google' | |
| service: 'gmail' | |
| status: 'connected' | 'revoked' | |
| scopes: string | |
| } | |
| export interface UserOAuthConnection { | |
| id: string | |
| user_id: string | |
| provider: 'google' | |
| service: 'gmail' | |
| status: 'connected' | 'revoked' | |
| scopes: string | |
| connected_at: string | |
| revoked_at?: string | |
| updated_at?: string | |
| } |
🤖 Prompt for AI Agents
In apps/web/types/types.ts around lines 682 to 689, the UserOAuthConnection
interface omits timestamp fields present in the DB schema; add connected_at:
string, revoked_at?: string (nullable/optional), and updated_at: string to the
interface and ensure revoked_at is optional to match the migration schema so
TypeScript matches Hasura query results.
🛠️ Refactor suggestion | 🟠 Major
Inflexible literal types prevent future extensibility.
The hardcoded literal types provider: 'google' and service: 'gmail' make this interface unusable for other providers (Microsoft, Apple) or services (calendar, drive). Consider using string types or a union of known values that can be extended:
provider: string // or 'google' | 'microsoft' | 'apple'
service: string // or 'gmail' | 'calendar' | 'drive'🔎 Proposed refactor for extensibility
+export type OAuthProvider = 'google' | 'microsoft' | 'apple'
+export type OAuthService = 'gmail' | 'calendar' | 'drive' | 'outlook'
+export type OAuthStatus = 'connected' | 'revoked'
+
export interface UserOAuthConnection {
id: string
user_id: string
- provider: 'google'
- service: 'gmail'
- status: 'connected' | 'revoked'
+ provider: OAuthProvider
+ service: OAuthService
+ status: OAuthStatus
scopes: string
+ connected_at: string
+ revoked_at?: string
}🤖 Prompt for AI Agents
In apps/web/types/types.ts around lines 682 to 689, the UserOAuthConnection
interface uses hardcoded literal types provider: 'google' and service: 'gmail'
which prevents adding other providers/services; change those properties to
broader types (either plain string or a union of known providers/services) so
the interface is extensible and can accept additional providers/services in the
future; update any dependent code types/consumers accordingly to handle the
wider type and, if using unions, add tests or type assertions for newly
supported values.
| export interface N8nCredential { | ||
| id: string | ||
| user_id: string | ||
| n8n_credential_id: string | ||
| service: 'gmail' | ||
| } |
There was a problem hiding this comment.
Schema mismatch: Missing fields from n8n_credentials table.
The N8nCredential interface is missing provider, created_at, and potentially updated_at fields from the database schema. It also uses an inflexible service: 'gmail' literal type.
🔎 Proposed fix
export interface N8nCredential {
id: string
user_id: string
+ provider: string
n8n_credential_id: string
- service: 'gmail'
+ service: string
+ created_at: string
+ updated_at?: string
}📝 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.
| export interface N8nCredential { | |
| id: string | |
| user_id: string | |
| n8n_credential_id: string | |
| service: 'gmail' | |
| } | |
| export interface N8nCredential { | |
| id: string | |
| user_id: string | |
| provider: string | |
| n8n_credential_id: string | |
| service: string | |
| created_at: string | |
| updated_at?: string | |
| } |
🤖 Prompt for AI Agents
In apps/web/types/types.ts around lines 692 to 697, the N8nCredential interface
is incomplete and too restrictive: it currently lacks the database fields
provider, created_at (and likely updated_at) and constrains service to the
literal 'gmail'. Update the interface to include provider: string; created_at:
string (or Date) and updated_at?: string | null (optional if DB allows null),
and change service to a more flexible string type (e.g., service: string) so it
matches the n8n_credentials schema and allows other providers.
| export interface UserWorkflow { | ||
| id: string | ||
| user_id: string | ||
| workflow_id: string | ||
| workflow_name: string | ||
| service: 'gmail' | ||
| } |
There was a problem hiding this comment.
Schema mismatch: Missing folder_path and timestamp fields.
The UserWorkflow interface is missing folder_path and created_at fields that exist in the database schema. Additionally, service: 'gmail' is overly restrictive.
🔎 Proposed fix to match database schema
export interface UserWorkflow {
id: string
user_id: string
workflow_id: string
workflow_name: string
- service: 'gmail'
+ service: string
+ folder_path: string
+ created_at: string
+ updated_at?: string
}🤖 Prompt for AI Agents
In apps/web/types/types.ts around lines 700 to 706, the UserWorkflow interface
is missing the database fields folder_path and created_at and currently
constrains service to the literal 'gmail'; update the interface to include
folder_path (string | null or optional string to reflect nullable DB column),
created_at (string in ISO timestamp format or Date depending on project
convention), and relax service to a more accurate type (string or a union of
allowed service literals instead of the single 'gmail').
…to fix-new-popup-issues
There was a problem hiding this comment.
Actionable comments posted: 14
🧹 Nitpick comments (5)
apps/web/app/api/automations/gmail/execute.ts (1)
1-3: Unused import and file format issues.
getHasuraClientis imported but never used in this file.- Same App Router format issue as other files—this should be
route.tswithNextRequest/NextResponse.-import { getHasuraClient, getUserWorkflowByService } from '@/services/hasura' +import { getUserWorkflowByService } from '@/services/hasura'apps/web/app/api/automations/gmail/disable.ts (1)
12-12: Unused Hasura client in current (broken) code path.The
clientvariable is created but never used in any reachable code path. Once the logic is fixed, ensure this is actually needed or remove if the delete can be done via a service function.apps/web/app/api/automations/gmail/enable.ts (2)
9-23: Consider centralizing environment variable validation.The IIFE pattern for environment variable validation works but leads to repetition. Consider extracting this into a reusable helper function or using a validation library like
zodfor environment variables.
30-31: Validate JWT is present before using it.The
jwtis read from the request body but never validated for presence before being passed to functions that require authentication. WhilegetUserWorkflowByServiceand other functions check for JWT internally, it's better to fail fast at the API boundary.🔎 Proposed fix
const { userId, jwt } = req.body - if (!userId) return res.status(400).json({ error: 'Missing userId' }) + if (!userId) return res.status(400).json({ error: 'Missing userId' }) + if (!jwt) return res.status(401).json({ error: 'Authentication required' })apps/web/services/hasura/hasura.service.ts (1)
2239-2266: Consider consolidating duplicate ISO timestamp generation.Multiple functions use
new Date().toISOString()for timestamp generation. Consider extracting this into a helper or using a consistent approach across all insertion functions.Also applies to: 2269-2294, 2297-2323
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
apps/web/app/api/automations/gmail/disable.tsapps/web/app/api/automations/gmail/enable.tsapps/web/app/api/automations/gmail/execute.tsapps/web/app/api/oauth/google/callback.tsapps/web/app/api/oauth/google/start.tsapps/web/lib/n8n.tsapps/web/services/hasura/hasura.service.tsapps/web/types/types.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/types/types.ts
🧰 Additional context used
📓 Path-based instructions (6)
apps/{web,pro-web}/app/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
apps/{web,pro-web}/app/**: Prefer Next.js Server Components; use 'use client' only when necessary
Leverage Streaming and Suspense for responsiveness in Next.js 15
Follow Next.js file conventions in the App Router
apps/{web,pro-web}/app/**: Leverage Server Components by default; use the use client directive only when client-side features are needed
Implement Nested Layouts using the App Router
Use Streaming and Suspense features in Next.js 14/15 where appropriate
Follow Next.js file conventions for routing and layout in the App Router
Optimize data fetching: fetch on the server, fetch where needed, and use preload patterns to avoid waterfalls
Files:
apps/web/app/api/oauth/google/start.tsapps/web/app/api/oauth/google/callback.tsapps/web/app/api/automations/gmail/enable.tsapps/web/app/api/automations/gmail/execute.tsapps/web/app/api/automations/gmail/disable.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Use meaningful variable names; prefix booleans with is/has/does/should
Use interface for objects/classes; type for unions/tuples/aliases; enum for fixed sets; const for literals
Avoid any; prefer specific types
Leverage type inference where clear; annotate function params and return types
Prefer type assertions with 'as' over angle-bracket syntax
Use type guards to narrow types in conditionals
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Use modern JavaScript features with TypeScript across the codebase
Use meaningful names; prefix booleans with is/has/does/should (e.g., isDisabled)
Receive an object and return an object (RORO) for functions interfacing with external services
Type definitions: use interface for objects/classes; type for unions/tuples/aliases; const for literals; enum for fixed sets
Avoid any; prefer specific types
Leverage type inference; omit explicit annotations when obvious
Add explicit type annotations for function parameters and return values
Prefer type assertions with as over angle-bracket syntax
Use type guards to narrow types within conditionals
Favor composition over inheritance in code structure
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Prefer RORO (Receive an object, return an object) for function signatures, especially for external service interactions
Use interface for object shapes/classes; type for unions/tuples/aliases; const for literals; enum for fixed enumerations
Avoid using any; prefer precise types
Leverage type inference when clear; omit redundant annotations
Explicitly annotate function parameters and return types
Prefer type assertions with as over angle-bracket syntax
Use type guards to narrow types safely
Use meaningful variable names; prefix booleans with is/has/does/should
Favor composition over inheritance
Use lowercase dash-separated names for files and folders; use extensions like .config.ts, .test.ts, .context.tsx, .typ...
Files:
apps/web/app/api/oauth/google/start.tsapps/web/app/api/oauth/google/callback.tsapps/web/app/api/automations/gmail/enable.tsapps/web/app/api/automations/gmail/execute.tsapps/web/app/api/automations/gmail/disable.tsapps/web/lib/n8n.tsapps/web/services/hasura/hasura.service.ts
apps/{web,pro-web}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
apps/{web,pro-web}/**/*.{ts,tsx}: Use lowercase kebab-case for directories and filenames (components can omit extension)
Verify DOM operations and consider timing (RAF/delays) when manipulating the DOM in React
Use Tailwind CSS utility classes for styling React components
apps/{web,pro-web}/**/*.{ts,tsx}: Use TypeScript to define React props types (interfaces for props)
Use custom hooks (useMBChat, useThread, useSidebar, useModel) for domain-specific state and keep providers focused and composed hierarchically
Separate presentation from business logic and compose small components
Use hasura.service.ts for all GraphQL operations from UI layers
apps/{web,pro-web}/**/*.{ts,tsx}: Prefer Server Components; use the use client directive only when client-side features are required
Implement Nested Layouts using the App Router
Use Streaming and Suspense in Next.js 14/15 where appropriate
Follow Next.js file conventions as per documentation
Use IndexedDB for local caching to enable immediate UI updates
Files:
apps/web/app/api/oauth/google/start.tsapps/web/app/api/oauth/google/callback.tsapps/web/app/api/automations/gmail/enable.tsapps/web/app/api/automations/gmail/execute.tsapps/web/app/api/automations/gmail/disable.tsapps/web/lib/n8n.tsapps/web/services/hasura/hasura.service.ts
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: Use lowercase with dash-separated directory and file names; use specific extensions: .config.ts, .test.ts, .context.tsx, .type.ts, .hook.ts; components may omit extension
Use Bun for package management and scripts instead of npm/yarn
Use Biome for formatting and linting via bun format-and-lint:fix; avoid Prettier/ESLint configs
Files:
apps/web/app/api/oauth/google/start.tsapps/web/app/api/oauth/google/callback.tsapps/web/app/api/automations/gmail/enable.tsapps/web/app/api/automations/gmail/execute.tsapps/web/app/api/automations/gmail/disable.tsapps/web/lib/n8n.tsapps/web/services/hasura/hasura.service.ts
apps/{web,pro-web}/services/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Place external API integrations under services/
Files:
apps/web/services/hasura/hasura.service.ts
apps/{web,pro-web}/services/**/*.ts
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use RORO (Receive an object, Return an object) for functions, especially when calling external services
Place external API integrations under services/
Files:
apps/web/services/hasura/hasura.service.ts
🧠 Learnings (10)
📓 Common learnings
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 0
File: :0-0
Timestamp: 2025-09-04T21:31:18.830Z
Learning: Successfully created comprehensive GitHub issue #555 consolidating performance feedback and edge-case management for pro-web workspace features, including prioritized action items, testing requirements, and specific file references for implementation.
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 0
File: :0-0
Timestamp: 2025-11-07T18:41:56.562Z
Learning: Successfully created comprehensive GitHub issue #581 consolidating 16 unresolved observations from PR #579 review, including critical TDZ crash, migration bugs, transaction safety issues, and validation improvements, with specific file paths, line numbers, and action items organized by priority (4 critical, 8 major, 2 minor, 2 acknowledged for future PRs).
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 0
File: :0-0
Timestamp: 2024-12-05T01:08:50.085Z
Learning: The backend uses Hasura with proper table relationships, permissions, and metadata structure defined in YAML configurations.
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Perform database schema changes via Hasura console (task console), then migrations (task migrate)
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 0
File: :0-0
Timestamp: 2024-12-05T01:08:50.085Z
Learning: The project is a monorepo using Turborepo with Next.js frontend (apps/masterbots.ai), Hasura backend (apps/hasura), and shared packages for types, GraphQL operations, and utilities.
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to apps/{web,pro-web}/**/ai-main-call.actions.{ts,tsx} : Route AI API handling through ai-main-call.actions for unified processing
Applied to files:
apps/web/app/api/oauth/google/callback.tsapps/web/app/api/automations/gmail/enable.tsapps/web/app/api/automations/gmail/disable.ts
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to apps/{web,pro-web}/**/*.{ts,tsx} : Follow Next.js file conventions as per documentation
Applied to files:
apps/web/app/api/oauth/google/callback.ts
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Use NextAuth.js with custom user management; JWT for API auth; roles/subscriptions for access control
Applied to files:
apps/web/app/api/oauth/google/callback.ts
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to **/services/hasura.service.ts : Use hasura.service.ts as the single interaction point for GraphQL operations with Hasura
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:08:30.965Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-09-30T22:08:30.965Z
Learning: Applies to **/services/hasura.service.ts : Use hasura.service.ts as the single point for all GraphQL interactions
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Applies to apps/{web,pro-web}/**/*.{ts,tsx} : Use hasura.service.ts for all GraphQL operations from UI layers
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Applies to apps/**/services/hasura.service.ts : Use hasura.service.ts as the single point of GraphQL interaction in each app
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-11-21T18:00:08.455Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 590
File: apps/web/lib/hooks/use-profile.tsx:60-78
Timestamp: 2025-11-21T18:00:08.455Z
Learning: In apps/web/lib/hooks/use-profile.tsx: The sessionUser state should be populated directly from session.user (JWT) and not by fetching from Hasura on the client side. The useEffect should only synchronize sessionUser with session.user. Client-side Hasura fetches for user data should be avoided; user data comes from the JWT/session. Only when users update their profile should we refresh both the database and JWT token (via NextAuth session update trigger).
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-05-06T09:54:25.327Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 468
File: apps/masterbots.ai/app/api/cron/delete-requested-accounts/route.ts:70-81
Timestamp: 2025-05-06T09:54:25.327Z
Learning: For Hasura GraphQL operations in server-side code (including API routes and cron jobs), use the `getHasuraClient()` function from mb-lib rather than implementing custom fetch functions. This provides proper error handling, environment validation, and follows the established pattern in the codebase.
Applied to files:
apps/web/services/hasura/hasura.service.ts
🧬 Code graph analysis (5)
apps/web/app/api/oauth/google/start.ts (1)
apps/web/app/api/oauth/google/callback.ts (1)
handler(44-123)
apps/web/app/api/oauth/google/callback.ts (4)
apps/web/app/api/oauth/google/start.ts (1)
handler(9-23)apps/web/lib/n8n.ts (3)
TokenData(1-7)createN8nCredential(10-43)duplicateN8nWorkflow(46-105)apps/web/types/types.ts (1)
TokenData(681-687)apps/web/services/hasura/hasura.service.ts (3)
insertUserOAuthConnection(2239-2266)insertN8nCredential(2269-2294)insertUserWorkflow(2297-2323)
apps/web/app/api/automations/gmail/enable.ts (6)
apps/web/app/api/automations/gmail/disable.ts (1)
handler(4-42)apps/web/app/api/automations/gmail/execute.ts (1)
handler(5-36)apps/web/app/api/oauth/google/callback.ts (1)
handler(44-123)apps/web/app/api/oauth/google/start.ts (1)
handler(9-23)apps/web/services/hasura/hasura.service.ts (3)
getUserWorkflowByService(2325-2351)getUserCredentialByService(2353-2378)insertUserWorkflow(2297-2323)apps/web/lib/n8n.ts (1)
duplicateN8nWorkflow(46-105)
apps/web/app/api/automations/gmail/execute.ts (1)
apps/web/services/hasura/hasura.service.ts (1)
getUserWorkflowByService(2325-2351)
apps/web/services/hasura/hasura.service.ts (2)
apps/web/services/hasura/hasura.service.type.ts (1)
GetHasuraClientParams(3-7)apps/web/types/types.ts (2)
UserWorkflow(708-716)UserCredential(722-727)
🔇 Additional comments (1)
apps/web/services/hasura/hasura.service.ts (1)
55-69: LGTM: getHasuraClient now properly exported.The function signature change to accept a parameters object follows best practices (RORO pattern) and makes the client reusable across the codebase.
| const userWorkflows = await getUserWorkflowByService(userId, 'gmail', jwt) | ||
| const workflowId = userWorkflows?.workflow_id | ||
|
|
||
| if (userWorkflows) { | ||
| return res.status(200).json({ | ||
| message: 'Workflow already enabled', | ||
| workflowId: userWorkflows.workflow_id, | ||
| }) | ||
| } | ||
|
|
||
| if (!userWorkflows) { | ||
| return res.status(400).json({ error: 'No workflow found for this user' }) | ||
| } | ||
|
|
||
| // Delete the workflow record from Hasura | ||
| await client.mutation({ | ||
| deleteUserWorkflows: { | ||
| __args: { where: { workflowId: { _eq: workflowId } } }, | ||
| affected_rows: true, | ||
| }, | ||
| }) | ||
|
|
||
| res.status(200).json({ message: 'Workflow disabled successfully' }) |
There was a problem hiding this comment.
Critical logic error: disable endpoint never actually disables.
The conditional logic is inverted and makes the delete operation unreachable:
- Line 17: If
userWorkflowsexists → returns 200 "Workflow already enabled" (wrong message for disable) - Line 24: If
userWorkflowsdoesn't exist → returns 400 - Lines 28-34: Delete mutation is unreachable since all code paths return before it
This means the disable endpoint can never actually delete a workflow.
🔎 Proposed fix
export default async function handler(
req: NextApiRequest,
res: NextApiResponse,
) {
try {
const { userId, jwt } = req.body
if (!userId) return res.status(400).json({ error: 'Missing userId' })
const client = getHasuraClient({ jwt })
const userWorkflows = await getUserWorkflowByService(userId, 'gmail', jwt)
- const workflowId = userWorkflows?.workflow_id
-
- if (userWorkflows) {
- return res.status(200).json({
- message: 'Workflow already enabled',
- workflowId: userWorkflows.workflow_id,
- })
- }
if (!userWorkflows) {
return res.status(400).json({ error: 'No workflow found for this user' })
}
+ const workflowId = userWorkflows.workflow_id
+
// Delete the workflow record from Hasura
await client.mutation({
deleteUserWorkflows: {
- __args: { where: { workflowId: { _eq: workflowId } } },
+ __args: { where: { workflow_id: { _eq: workflowId } } },
affected_rows: true,
},
})
res.status(200).json({ message: 'Workflow disabled successfully' })🤖 Prompt for AI Agents
In apps/web/app/api/automations/gmail/disable.ts around lines 14 to 36, the
conditional logic is inverted so the delete code never runs: change the flow to
return 400 if no userWorkflows, and otherwise perform the delete and then return
a 200 success; remove the early return that says "Workflow already enabled" and
instead run the client.mutation when userWorkflows exists, then return a clear
"Workflow disabled successfully" response; also ensure you use the correct
workflow ID variable/DB column name in the delete where clause (match
workflow_id vs workflowId).
| throw new Error('N8N_WEBHOOK_BASE_URL is not defined') | ||
| })() | ||
|
|
||
| export default async function handler( |
There was a problem hiding this comment.
Use named export instead of default export.
The coding guidelines specify: "Avoid default exports; prefer named exports."
🔎 Proposed fix
-export default async function handler(
+export async function handler(
req: NextApiRequest,
res: NextApiResponse,
) {Based on coding guidelines.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In apps/web/app/api/automations/gmail/enable.ts around line 25, the handler is
exported as a default export; change it to a named export (export async function
handler(...)) and update any imports or references to use the named export
(import { handler } from '...') so code follows the "no default exports"
guideline; ensure TypeScript/server framework routing (if it relies on default)
is adjusted to accept the named export or add an explicit re-export where
necessary.
| await insertUserWorkflow( | ||
| userId, | ||
| workflow.id, | ||
| workflow.name, | ||
| 'gmail', | ||
| 'Masterbots/Users Workflows/Email', | ||
| jwt, | ||
| ) |
There was a problem hiding this comment.
Critical: Parameter order mismatch causes runtime error.
The call to insertUserWorkflow passes parameters in the wrong order. The function signature in hasura.service.ts (line 2297) expects jwt as the first parameter, but you're passing it last.
🔎 Proposed fix
await insertUserWorkflow(
+ jwt,
userId,
workflow.id,
workflow.name,
'gmail',
'Masterbots/Users Workflows/Email',
- jwt,
)📝 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.
| await insertUserWorkflow( | |
| userId, | |
| workflow.id, | |
| workflow.name, | |
| 'gmail', | |
| 'Masterbots/Users Workflows/Email', | |
| jwt, | |
| ) | |
| await insertUserWorkflow( | |
| jwt, | |
| userId, | |
| workflow.id, | |
| workflow.name, | |
| 'gmail', | |
| 'Masterbots/Users Workflows/Email', | |
| ) |
🤖 Prompt for AI Agents
In apps/web/app/api/automations/gmail/enable.ts around lines 65-72, the call to
insertUserWorkflow passes arguments in the wrong order (jwt is last) while the
hasura.service.ts signature expects jwt as the first parameter; reorder the call
so jwt is passed first followed by userId, workflow.id, workflow.name, 'gmail',
'Masterbots/Users Workflows/Email' to match the function signature.
| const triggerRes = await fetch(webhookUrl, { | ||
| method: 'POST', | ||
| headers: { 'Content-Type': 'application/json' }, | ||
| body: JSON.stringify(payload || {}), | ||
| }) | ||
|
|
||
| const triggerData = await triggerRes.json() | ||
|
|
||
| res.status(200).json({ message: 'Workflow executed', data: triggerData }) |
There was a problem hiding this comment.
Missing error handling for webhook trigger response.
The code assumes the webhook call succeeds without checking triggerRes.ok. If the n8n webhook returns an error status, this should be surfaced to the caller.
🔎 Proposed fix
// 2️⃣ Trigger workflow via POST
const triggerRes = await fetch(webhookUrl, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(payload || {}),
})
const triggerData = await triggerRes.json()
+ if (!triggerRes.ok) {
+ return res.status(triggerRes.status).json({
+ error: 'Failed to trigger workflow',
+ details: triggerData,
+ })
+ }
res.status(200).json({ message: 'Workflow executed', data: triggerData })📝 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 triggerRes = await fetch(webhookUrl, { | |
| method: 'POST', | |
| headers: { 'Content-Type': 'application/json' }, | |
| body: JSON.stringify(payload || {}), | |
| }) | |
| const triggerData = await triggerRes.json() | |
| res.status(200).json({ message: 'Workflow executed', data: triggerData }) | |
| const triggerRes = await fetch(webhookUrl, { | |
| method: 'POST', | |
| headers: { 'Content-Type': 'application/json' }, | |
| body: JSON.stringify(payload || {}), | |
| }) | |
| const triggerData = await triggerRes.json() | |
| if (!triggerRes.ok) { | |
| return res.status(triggerRes.status).json({ | |
| error: 'Failed to trigger workflow', | |
| details: triggerData, | |
| }) | |
| } | |
| res.status(200).json({ message: 'Workflow executed', data: triggerData }) |
🤖 Prompt for AI Agents
In apps/web/app/api/automations/gmail/execute.ts around lines 22 to 30, the code
posts to the webhook but does not check triggerRes.ok or handle fetch errors;
update the implementation to check triggerRes.ok and, if false, read the
response body (await triggerRes.text() or json when possible) and return a
non-200 response to the caller (e.g., res.status(triggerRes.status).json({
message: 'Webhook error', status: triggerRes.status, details: <body> })), and
wrap the fetch in try/catch to handle network/throwing errors and return a
502/500 with the error message if the fetch itself fails.
| const { code, state } = req.query | ||
| const userId = state as string | ||
| const jwt = req.headers.authorization?.split(' ')[1] | ||
|
|
||
| if (!code || !userId) | ||
| return res.status(400).json({ error: 'Missing code or userId' }) |
There was a problem hiding this comment.
JWT will not be available in OAuth callback redirects.
OAuth callbacks are browser redirects from Google, which means no Authorization header will be present. The JWT extraction on line 51 will always result in undefined, causing the subsequent Hasura operations to fail (they throw if JWT is missing).
Consider alternative approaches:
- Pass the JWT in the
stateparameter (encrypted/signed) along with userId - Use server-side session to retrieve the JWT
- Create a separate authenticated endpoint that the frontend calls after redirect
🤖 Prompt for AI Agents
In apps/web/app/api/oauth/google/callback.ts around lines 49–54, the code tries
to read a JWT from req.headers.authorization which will be undefined on Google
redirect callbacks; remove reliance on the Authorization header and instead
retrieve the JWT from a safe alternative: either decode/verify a
signed+encrypted payload passed via the state parameter (e.g., state contains an
encrypted JSON with userId and jwt; validate signature and decrypt to extract
both), or look up the JWT from a server-side session store keyed by a secure
state value, or convert this flow to have the frontend read the callback and
then call a separate authenticated backend endpoint; implement one of these
approaches and update the missing-token check to use the JWT obtained from that
mechanism rather than req.headers.authorization.
| ) { | ||
| if (!jwt) | ||
| throw new Error('Authentication required to insert OAuth connection') |
There was a problem hiding this comment.
Incorrect error message.
The error message says "insert OAuth connection" but this function inserts N8N credentials, not OAuth connections.
🔎 Proposed fix
if (!jwt)
- throw new Error('Authentication required to insert OAuth connection')
+ throw new Error('Authentication required to insert N8N credential')📝 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.
| ) { | |
| if (!jwt) | |
| throw new Error('Authentication required to insert OAuth connection') | |
| ) { | |
| if (!jwt) | |
| throw new Error('Authentication required to insert N8N credential') |
🤖 Prompt for AI Agents
In apps/web/services/hasura/hasura.service.ts around lines 2274 to 2276, the
thrown error message incorrectly references "insert OAuth connection" though
this function inserts N8N credentials; update the thrown Error to reflect the
correct operation (for example: "Authentication required to insert N8N
credentials") so the message accurately describes the failure context.
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In @apps/web/app/api/oauth/google/callback/route.ts:
- Around line 50-70: The GET handler is missing validation of the OAuth state
parameter; read the incoming state via url.searchParams.get('state') and compare
it against the expected value tied to the authenticated session (e.g.,
session.user.id or a session-stored CSRF token), and if it’s missing or does not
match return a 400/401 error (similar to the existing missing-code/userId
branch); update the GET function to perform this check before exchanging code
and include a clear error response on mismatch to prevent CSRF.
In @apps/web/app/api/oauth/google/start/route.ts:
- Around line 17-49: The GET handler exposes userId from the querystring and
logs it, causing auth bypass, CSRF risk and PII leakage; update the GET function
to require and validate an authenticated session (e.g., obtain the current
userId from your session/auth middleware instead of url.searchParams.get),
return 401 if no authenticated user, ensure the requested userId (if ever
passed) matches the session user, remove any console.log of userId/PII, and
implement a secure CSRF/state flow by generating a cryptographically random
state tied to the session (store it server-side or in a signed cookie) and use
that state parameter in the URLSearchParams before redirecting to Google; keep
the redirect building logic (URLSearchParams, authUrl) but only after these
checks and state creation and log only non-PII debug info.
In @apps/web/app/api/test-google-start/route.ts:
- Around line 1-10: This test API route (exported GET in route.ts) is an
unauthenticated debug endpoint and must be removed before merging; delete the
file that defines the GET handler (apps/web/app/api/test-google-start/route.ts)
or, if you absolutely need runtime testing, replace the export with a
non-deployed guard: remove the GET export or wrap it behind a development-only
feature flag or explicit environment check so it cannot be invoked in
production.
🧹 Nitpick comments (1)
apps/web/app/api/oauth/google/callback/route.ts (1)
99-134: Consider adding transaction handling for multi-step workflow.The OAuth callback performs 5 database/external operations sequentially (lines 100-134). If any step after the first fails, earlier steps are not rolled back, potentially leaving orphaned records in the database (e.g., OAuth connections without corresponding workflows).
While this may be acceptable depending on your error recovery strategy, consider whether you need:
- Transaction boundaries to ensure atomicity
- Idempotency keys to allow safe retries
- Cleanup logic in the catch block to remove partial state
Based on learnings, in
apps/pro-web/app/actions/admin.actions.ts, the team uses Drizzle DB transactions to ensure atomicity when inserting related records.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/web/app/api/oauth/google/callback/route.tsapps/web/app/api/oauth/google/start/route.tsapps/web/app/api/test-google-start/route.ts
🧰 Additional context used
📓 Path-based instructions (4)
apps/{web,pro-web}/app/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
apps/{web,pro-web}/app/**: Prefer Next.js Server Components; use 'use client' only when necessary
Leverage Streaming and Suspense for responsiveness in Next.js 15
Follow Next.js file conventions in the App Router
apps/{web,pro-web}/app/**: Leverage Server Components by default; use the use client directive only when client-side features are needed
Implement Nested Layouts using the App Router
Use Streaming and Suspense features in Next.js 14/15 where appropriate
Follow Next.js file conventions for routing and layout in the App Router
Optimize data fetching: fetch on the server, fetch where needed, and use preload patterns to avoid waterfalls
Files:
apps/web/app/api/oauth/google/callback/route.tsapps/web/app/api/oauth/google/start/route.tsapps/web/app/api/test-google-start/route.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Use meaningful variable names; prefix booleans with is/has/does/should
Use interface for objects/classes; type for unions/tuples/aliases; enum for fixed sets; const for literals
Avoid any; prefer specific types
Leverage type inference where clear; annotate function params and return types
Prefer type assertions with 'as' over angle-bracket syntax
Use type guards to narrow types in conditionals
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Use modern JavaScript features with TypeScript across the codebase
Use meaningful names; prefix booleans with is/has/does/should (e.g., isDisabled)
Receive an object and return an object (RORO) for functions interfacing with external services
Type definitions: use interface for objects/classes; type for unions/tuples/aliases; const for literals; enum for fixed sets
Avoid any; prefer specific types
Leverage type inference; omit explicit annotations when obvious
Add explicit type annotations for function parameters and return values
Prefer type assertions with as over angle-bracket syntax
Use type guards to narrow types within conditionals
Favor composition over inheritance in code structure
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Prefer RORO (Receive an object, return an object) for function signatures, especially for external service interactions
Use interface for object shapes/classes; type for unions/tuples/aliases; const for literals; enum for fixed enumerations
Avoid using any; prefer precise types
Leverage type inference when clear; omit redundant annotations
Explicitly annotate function parameters and return types
Prefer type assertions with as over angle-bracket syntax
Use type guards to narrow types safely
Use meaningful variable names; prefix booleans with is/has/does/should
Favor composition over inheritance
Use lowercase dash-separated names for files and folders; use extensions like .config.ts, .test.ts, .context.tsx, .typ...
Files:
apps/web/app/api/oauth/google/callback/route.tsapps/web/app/api/oauth/google/start/route.tsapps/web/app/api/test-google-start/route.ts
apps/{web,pro-web}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
apps/{web,pro-web}/**/*.{ts,tsx}: Use lowercase kebab-case for directories and filenames (components can omit extension)
Verify DOM operations and consider timing (RAF/delays) when manipulating the DOM in React
Use Tailwind CSS utility classes for styling React components
apps/{web,pro-web}/**/*.{ts,tsx}: Use TypeScript to define React props types (interfaces for props)
Use custom hooks (useMBChat, useThread, useSidebar, useModel) for domain-specific state and keep providers focused and composed hierarchically
Separate presentation from business logic and compose small components
Use hasura.service.ts for all GraphQL operations from UI layers
apps/{web,pro-web}/**/*.{ts,tsx}: Prefer Server Components; use the use client directive only when client-side features are required
Implement Nested Layouts using the App Router
Use Streaming and Suspense in Next.js 14/15 where appropriate
Follow Next.js file conventions as per documentation
Use IndexedDB for local caching to enable immediate UI updates
Files:
apps/web/app/api/oauth/google/callback/route.tsapps/web/app/api/oauth/google/start/route.tsapps/web/app/api/test-google-start/route.ts
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: Use lowercase with dash-separated directory and file names; use specific extensions: .config.ts, .test.ts, .context.tsx, .type.ts, .hook.ts; components may omit extension
Use Bun for package management and scripts instead of npm/yarn
Use Biome for formatting and linting via bun format-and-lint:fix; avoid Prettier/ESLint configs
Files:
apps/web/app/api/oauth/google/callback/route.tsapps/web/app/api/oauth/google/start/route.tsapps/web/app/api/test-google-start/route.ts
🧠 Learnings (6)
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to apps/{web,pro-web}/**/ai-main-call.actions.{ts,tsx} : Route AI API handling through ai-main-call.actions for unified processing
Applied to files:
apps/web/app/api/oauth/google/callback/route.tsapps/web/app/api/test-google-start/route.ts
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to apps/{web,pro-web}/**/*.{ts,tsx} : Follow Next.js file conventions as per documentation
Applied to files:
apps/web/app/api/oauth/google/callback/route.tsapps/web/app/api/test-google-start/route.ts
📚 Learning: 2025-11-07T18:38:42.273Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 579
File: apps/pro-web/app/api/auth/signup/route.ts:151-157
Timestamp: 2025-11-07T18:38:42.273Z
Learning: In apps/pro-web/app/actions/admin.actions.ts, the insertUserOrganizations function should use Drizzle DB transactions to ensure atomicity when inserting organizations and their associated chatbots, preventing partial persistence issues.
Applied to files:
apps/web/app/api/oauth/google/callback/route.ts
📚 Learning: 2025-11-21T18:00:08.455Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 590
File: apps/web/lib/hooks/use-profile.tsx:60-78
Timestamp: 2025-11-21T18:00:08.455Z
Learning: In apps/web/lib/hooks/use-profile.tsx: The sessionUser state should be populated directly from session.user (JWT) and not by fetching from Hasura on the client side. The useEffect should only synchronize sessionUser with session.user. Client-side Hasura fetches for user data should be avoided; user data comes from the JWT/session. Only when users update their profile should we refresh both the database and JWT token (via NextAuth session update trigger).
Applied to files:
apps/web/app/api/oauth/google/callback/route.ts
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Applies to apps/{web,pro-web}/app/** : Follow Next.js file conventions for routing and layout in the App Router
Applied to files:
apps/web/app/api/test-google-start/route.ts
📚 Learning: 2025-09-30T22:08:30.965Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-09-30T22:08:30.965Z
Learning: Applies to apps/{web,pro-web}/app/** : Follow Next.js file conventions in the App Router
Applied to files:
apps/web/app/api/test-google-start/route.ts
🧬 Code graph analysis (3)
apps/web/app/api/oauth/google/callback/route.ts (3)
apps/web/app/api/oauth/google/start/route.ts (1)
GET(17-49)apps/web/services/hasura/hasura.service.ts (3)
insertUserOAuthConnection(2239-2266)insertN8nCredential(2269-2294)insertUserWorkflow(2297-2323)apps/web/lib/n8n.ts (2)
createN8nCredential(10-43)duplicateN8nWorkflow(46-105)
apps/web/app/api/oauth/google/start/route.ts (2)
apps/web/app/api/oauth/google/callback/route.ts (1)
GET(50-148)apps/web/app/api/test-google-start/route.ts (1)
GET(3-10)
apps/web/app/api/test-google-start/route.ts (2)
apps/web/app/api/oauth/google/callback/route.ts (1)
GET(50-148)apps/web/app/api/oauth/google/start/route.ts (1)
GET(17-49)
🔇 Additional comments (4)
apps/web/app/api/oauth/google/start/route.ts (1)
3-15: LGTM!Environment variable validation with IIFE pattern ensures the route fails fast on misconfiguration. The scope definition is appropriate for Gmail access.
apps/web/app/api/oauth/google/callback/route.ts (3)
15-48: LGTM!Environment variable validation is comprehensive and uses the IIFE pattern appropriately to fail fast on misconfiguration.
136-147: LGTM with minor note on error exposure.The error handling pattern is appropriate. One consideration: returning
error.messageon Line 144 might expose internal details. If errors could contain sensitive information, consider sanitizing or using a generic message for client responses while logging the full error server-side (which you already do on Line 142).
99-134: Critical: Parameter order mismatch ininsertUserWorkflowcall.According to
apps/web/services/hasura/hasura.service.ts(lines 2296-2322),insertUserWorkflowexpects parameters in this order:insertUserWorkflow(jwt, userId, workflowId, workflowName, service, folderPath)However, lines 127-134 pass them as:
insertUserWorkflow(userId, workflow.id, workflow.name, 'gmail', 'Masterbots/Users Workflows/Email', jwt)This will cause runtime errors or incorrect data persistence.
🔧 Proposed fix
// 6️⃣ Store workflow info in Hasura await insertUserWorkflow( + jwt, userId, workflow.id, workflow.name, 'gmail', 'Masterbots/Users Workflows/Email', - jwt, )⛔ Skipped due to learnings
Learnt from: AndlerRL Repo: bitcashorg/masterbots PR: 579 File: apps/pro-web/app/api/auth/signup/route.ts:151-157 Timestamp: 2025-11-07T18:38:42.273Z Learning: In apps/pro-web/app/actions/admin.actions.ts, the insertUserOrganizations function should use Drizzle DB transactions to ensure atomicity when inserting organizations and their associated chatbots, preventing partial persistence issues.
| export async function GET(req: NextRequest) { | ||
| try { | ||
| const session = await getServerSession(authOptions) | ||
| if (!session) { | ||
| return NextResponse.json( | ||
| { error: 'User not authenticated' }, | ||
| { status: 401 }, | ||
| ) | ||
| } | ||
|
|
||
| const jwt = session.user.hasuraJwt | ||
| const userId = session.user.id | ||
| const url = new URL(req.url) | ||
| const code = url.searchParams.get('code') | ||
|
|
||
| if (!code || !userId) { | ||
| return NextResponse.json( | ||
| { error: 'Missing code or userId' }, | ||
| { status: 400 }, | ||
| ) | ||
| } |
There was a problem hiding this comment.
Missing CSRF state parameter validation.
While session authentication is correctly implemented, the OAuth state parameter returned by Google is not validated. The state should be checked to ensure it matches the userId from the session to prevent CSRF attacks where an attacker tricks a victim into completing an OAuth flow for the attacker's account.
🔒 Proposed fix for state validation
const jwt = session.user.hasuraJwt
const userId = session.user.id
const url = new URL(req.url)
const code = url.searchParams.get('code')
+ const state = url.searchParams.get('state')
- if (!code || !userId) {
+ if (!code || !userId || !state) {
return NextResponse.json(
- { error: 'Missing code or userId' },
+ { error: 'Missing code, userId, or state' },
{ status: 400 },
)
}
+
+ // Validate state parameter matches userId to prevent CSRF
+ const decodedState = decodeURIComponent(state)
+ if (decodedState !== userId) {
+ return NextResponse.json(
+ { error: 'Invalid state parameter' },
+ { status: 400 },
+ )
+ }
console.log('Google callback hit for userId:', userId)🤖 Prompt for AI Agents
In @apps/web/app/api/oauth/google/callback/route.ts around lines 50 - 70, The
GET handler is missing validation of the OAuth state parameter; read the
incoming state via url.searchParams.get('state') and compare it against the
expected value tied to the authenticated session (e.g., session.user.id or a
session-stored CSRF token), and if it’s missing or does not match return a
400/401 error (similar to the existing missing-code/userId branch); update the
GET function to perform this check before exchanging code and include a clear
error response on mismatch to prevent CSRF.
| console.log('Google callback hit for userId:', userId) | ||
|
|
||
| // 1️⃣ Exchange code for tokens | ||
| const params = new URLSearchParams({ | ||
| code, | ||
| client_id: GOOGLE_CLIENT_ID, | ||
| client_secret: GOOGLE_CLIENT_SECRET, | ||
| redirect_uri: REDIRECT_URI, | ||
| grant_type: 'authorization_code', | ||
| }) | ||
|
|
||
| const tokenRes = await fetch('https://oauth2.googleapis.com/token', { | ||
| method: 'POST', | ||
| headers: { 'Content-Type': 'application/x-www-form-urlencoded' }, | ||
| body: params.toString(), | ||
| }) | ||
|
|
||
| const tokenData: TokenData = await tokenRes.json() | ||
| if (!tokenData.access_token) { | ||
| return NextResponse.json( | ||
| { error: 'No access_token returned from Google' }, | ||
| { status: 400 }, | ||
| ) | ||
| } | ||
|
|
||
| console.log('Received Google tokens for userId:', userId) |
There was a problem hiding this comment.
Remove PII from logs and add fetch timeout.
Two issues:
- Compliance concern: Lines 72 and 97 log
userId, which is personally identifiable information. This may violate GDPR/CCPA requirements. - Reliability gap: The
fetchcall on Line 83 has no timeout, which could cause the request to hang indefinitely if Google's API is slow or unresponsive.
♻️ Proposed improvements
- console.log('Google callback hit for userId:', userId)
+ console.log('Google callback hit')
// 1️⃣ Exchange code for tokens
const params = new URLSearchParams({
code,
client_id: GOOGLE_CLIENT_ID,
client_secret: GOOGLE_CLIENT_SECRET,
redirect_uri: REDIRECT_URI,
grant_type: 'authorization_code',
})
+ const controller = new AbortController()
+ const timeoutId = setTimeout(() => controller.abort(), 10000) // 10s timeout
+
const tokenRes = await fetch('https://oauth2.googleapis.com/token', {
method: 'POST',
headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
body: params.toString(),
+ signal: controller.signal,
})
+ clearTimeout(timeoutId)
const tokenData: TokenData = await tokenRes.json()
if (!tokenData.access_token) {
return NextResponse.json(
{ error: 'No access_token returned from Google' },
{ status: 400 },
)
}
- console.log('Received Google tokens for userId:', userId)
+ console.log('Received Google tokens')| export async function GET(req: NextRequest) { | ||
| try { | ||
| const url = new URL(req.url) | ||
| const userId = url.searchParams.get('userId') | ||
|
|
||
| if (!userId) { | ||
| return NextResponse.json({ error: 'Missing userId' }, { status: 400 }) | ||
| } | ||
|
|
||
| console.log('Google start route hit with userId:', userId) | ||
|
|
||
| const params = new URLSearchParams({ | ||
| client_id: GOOGLE_CLIENT_ID, | ||
| redirect_uri: REDIRECT_URI, | ||
| response_type: 'code', | ||
| scope: SCOPES.join(' '), | ||
| access_type: 'offline', | ||
| prompt: 'consent', | ||
| state: encodeURIComponent(userId), | ||
| }) | ||
|
|
||
| const authUrl = `https://accounts.google.com/o/oauth2/v2/auth?${params.toString()}` | ||
| console.log('Redirecting to Google OAuth URL:', authUrl) | ||
|
|
||
| return NextResponse.redirect(authUrl) | ||
| } catch (err) { | ||
| console.error('Error in Google start route:', err) | ||
| return NextResponse.json( | ||
| { error: 'Internal server error' }, | ||
| { status: 500 }, | ||
| ) | ||
| } | ||
| } |
There was a problem hiding this comment.
Critical: Missing authentication and insecure userId handling.
This endpoint has several security vulnerabilities:
- No authentication check: Anyone can initiate OAuth for any user by passing an arbitrary
userIdin the query string - CSRF vulnerability: No validation that the requester owns the
userId - PII logging: Line 26 logs
userId, which is personally identifiable information
The userId should be extracted from an authenticated session (like in the callback route), not from query parameters.
🔒 Proposed security fixes
+import { authOptions } from '@/auth'
+import { getServerSession } from 'next-auth'
import { type NextRequest, NextResponse } from 'next/server'
const GOOGLE_CLIENT_ID =
process.env.GOOGLE_CLIENT_ID ??
(() => {
throw new Error('Missing GOOGLE_CLIENT_ID environment variable')
})()
const REDIRECT_URI =
process.env.NEXT_PUBLIC_GOOGLE_OAUTH_REDIRECT_URI ??
(() => {
throw new Error(
'Missing NEXT_PUBLIC_GOOGLE_OAUTH_REDIRECT_URI environment variable',
)
})()
const SCOPES = ['https://www.googleapis.com/auth/gmail.modify']
export async function GET(req: NextRequest) {
try {
+ const session = await getServerSession(authOptions)
+ if (!session) {
+ return NextResponse.json(
+ { error: 'User not authenticated' },
+ { status: 401 },
+ )
+ }
+
- const url = new URL(req.url)
- const userId = url.searchParams.get('userId')
-
- if (!userId) {
- return NextResponse.json({ error: 'Missing userId' }, { status: 400 })
- }
-
- console.log('Google start route hit with userId:', userId)
+ const userId = session.user.id
const params = new URLSearchParams({
client_id: GOOGLE_CLIENT_ID,
redirect_uri: REDIRECT_URI,
response_type: 'code',
scope: SCOPES.join(' '),
access_type: 'offline',
prompt: 'consent',
state: encodeURIComponent(userId),
})
const authUrl = `https://accounts.google.com/o/oauth2/v2/auth?${params.toString()}`
- console.log('Redirecting to Google OAuth URL:', authUrl)
return NextResponse.redirect(authUrl)
} catch (err) {
console.error('Error in Google start route:', err)
return NextResponse.json(
{ error: 'Internal server error' },
{ status: 500 },
)
}
}🤖 Prompt for AI Agents
In @apps/web/app/api/oauth/google/start/route.ts around lines 17 - 49, The GET
handler exposes userId from the querystring and logs it, causing auth bypass,
CSRF risk and PII leakage; update the GET function to require and validate an
authenticated session (e.g., obtain the current userId from your session/auth
middleware instead of url.searchParams.get), return 401 if no authenticated
user, ensure the requested userId (if ever passed) matches the session user,
remove any console.log of userId/PII, and implement a secure CSRF/state flow by
generating a cryptographically random state tied to the session (store it
server-side or in a signed cookie) and use that state parameter in the
URLSearchParams before redirecting to Google; keep the redirect building logic
(URLSearchParams, authUrl) but only after these checks and state creation and
log only non-PII debug info.
| import { type NextRequest, NextResponse } from 'next/server' | ||
|
|
||
| export async function GET(req: NextRequest) { | ||
| const url = new URL(req.url) | ||
| const userId = url.searchParams.get('userId') | ||
|
|
||
| console.log('Test route hit!', userId) | ||
|
|
||
| return NextResponse.json({ message: 'Route works', userId }) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Remove test route before merging to production.
This test endpoint has no authentication and appears to be for debugging purposes only. Test/debug routes should not be committed to the main codebase, especially in a production branch like develop.
🧹 Recommended action
Remove this file entirely before merging. If route testing is needed during development, use local-only files or feature flags to prevent test routes from being deployed.
🤖 Prompt for AI Agents
In @apps/web/app/api/test-google-start/route.ts around lines 1 - 10, This test
API route (exported GET in route.ts) is an unauthenticated debug endpoint and
must be removed before merging; delete the file that defines the GET handler
(apps/web/app/api/test-google-start/route.ts) or, if you absolutely need runtime
testing, replace the export with a non-deployed guard: remove the GET export or
wrap it behind a development-only feature flag or explicit environment check so
it cannot be invoked in production.
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/web/auth.ts (1)
67-84: Critical: Password validation is disabled - authentication bypass vulnerability.The bcrypt password comparison result (
isValid) is computed but the validation check is commented out. This allows any user to authenticate with any password as long as their email exists in the database, completely bypassing credential verification.This must be restored before merging:
🔒 Required fix to restore password validation
//* Verify the password using bcrypt (hash comparison) const isValid = bcrypt.compareSync( credentials.password, user[0].password, ) - // if (!isValid) { - // console.error('NextUser authentication failed: Invalid password') - // throw new Error('Invalid credentials') - // } + if (!isValid) { + console.error('NextUser authentication failed: Invalid password') + throw new Error('Invalid credentials') + } console.log('NextUser authenticated successfully')
🤖 Fix all issues with AI agents
In
`@apps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/down.sql`:
- Around line 1-2: The down migration is identical to the up migration causing a
no-op; fix by ensuring up.sql and down.sql are complementary for the constraint
"user_oauth_connections_user_id_key" on table "public"."user_oauth_connections":
if the intent is to add a unique constraint, make up.sql only add the constraint
and make down.sql only drop the constraint (DROP CONSTRAINT
"user_oauth_connections_user_id_key"), or if the constraint already exists
remove this migration entirely; update the SQL files so up adds and down removes
the unique constraint (or delete the migration) and then re-run migrations to
verify correct behavior.
In
`@apps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/up.sql`:
- Around line 1-2: The migration is a no-op and its down.sql is wrong: it drops
and re-adds the existing constraint "user_oauth_connections_user_id_key" (from
migration 1766066591567) then repeats the same in down.sql; either delete this
migration or implement a real change. Fix by either removing this migration file
pair entirely if no schema change is needed, or if you intended a rename or
change, modify up.sql to perform the actual change (e.g., rename constraint or
alter uniqueness) and update down.sql to reverse that change; reference the
constraint name "user_oauth_connections_user_id_key" and the migration id
1768003427670 when making the edits so both up.sql and down.sql are
complementary and no longer a bidirectional no-op.
In
`@apps/hasura/migrations/masterbots/1768003836473_alter_table_public_user_oauth_connections_alter_column_revoked_at/down.sql`:
- Line 1: The down migration alters user_oauth_connections.revoked_at to NOT
NULL which will fail if any NULLs exist; before running ALTER TABLE
"user_oauth_connections" ALTER COLUMN "revoked_at" SET NOT NULL you must handle
existing NULL values (e.g. UPDATE user_oauth_connections SET revoked_at =
<safe_default_timestamp> WHERE revoked_at IS NULL, or DELETE/flag those rows, or
decide to skip/remove the NOT NULL change), or alternatively make the migration
idempotent by checking for NULLs and only applying the constraint when none
exist; update the down migration to perform the NULL-handling step(s) and
document the chosen semantic for revoked_at so rollback won't error.
In `@apps/web/services/hasura/hasura.service.ts`:
- Around line 2386-2390: The returned object includes a hardcoded empty
webhook_url which can mislead callers; update the code that builds the
UserCredential (the return using result.n8nCredentials[0] and casting to
UserCredential) to either (a) retrieve the real webhook URL from the DB result
(e.g., include the webhook field from result.n8nCredentials[0] or join the table
that contains it) and set webhook_url to that value, or (b) change the return
type to a narrower interface that omits webhook_url, or (c) make webhook_url
optional on the UserCredential type and omit it when not available—choose one
approach and remove the hardcoded '' placeholder so callers do not receive a
false empty URL.
- Around line 2299-2332: The insertUserWorkflow function should validate the jwt
before calling getHasuraClient: if jwt is falsy, throw the same error used by
getUserWorkflowByService (e.g., throw new Error('JWT is required') or match its
exact message) to maintain consistency; add this check at the start of
insertUserWorkflow (before getHasuraClient) so getHasuraClient is only called
with a valid token and the error behavior matches other functions in this file.
♻️ Duplicate comments (4)
apps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yaml (1)
1-3: Missing object relationship to the user table.The table lacks an
object_relationshipsdefinition to linkuser_idtopublic.user. This relationship is important for GraphQL query traversal and data integrity.♻️ Add object relationship
table: name: user_oauth_connections schema: public object_relationships: - name: user using: foreign_key_constraint_on: user_idapps/web/services/hasura/hasura.service.ts (2)
2276-2277: Incorrect error message.The error message says "insert OAuth connection" but this function inserts N8N credentials.
🔎 Proposed fix
if (!jwt) - throw new Error('Authentication required to insert OAuth connection') + throw new Error('Authentication required to insert N8N credential')
2342-2359: Type assertion mismatch - onlyworkflow_idis queried but fullUserWorkflowtype is asserted.The query only selects
workflow_idbut the return value is cast toUserWorkflow. IfUserWorkflowhas additional required fields (likeid,user_id,workflow_name,service,folder_path,created_at), callers may encounter runtime errors when accessing undefined properties.Either expand the query to fetch all fields or define a narrower return type.
🔎 Proposed fix - expand query fields
const result = await client.query({ userWorkflows: { - workflow_id: true, + id: true, + userId: true, + workflowId: true, + workflowName: true, + service: true, + folderPath: true, + createdAt: true, __args: { where: { userId: { _eq: userId }, service: { _eq: service }, }, limit: 1, }, }, })apps/web/app/api/test-google-start/route.ts (1)
1-41: Remove test route before merging to production.This test endpoint exposes sensitive information (session data and JWT) in the response and contains mock/debug code. Test routes should not be committed to the
developbranch.Additional concerns:
- Line 1: Unused import
insertUserOAuthConnection(the call is commented out)- Lines 25-32: Mock token data serves no purpose
- Line 40: Response leaks
sessionandjwtwhich could aid attackers🧹 Recommended action
Delete this file entirely before merging. If OAuth flow testing is needed during development, use:
- Local-only test scripts outside the committed codebase
- Environment-gated routes that only run in development:
if (process.env.NODE_ENV === 'production') { return NextResponse.json({ error: 'Not found' }, { status: 404 }) }
🧹 Nitpick comments (3)
apps/hasura/migrations/masterbots/1768100057144_alter_table_public_user_workflows_alter_column_id/down.sql (1)
1-1: LGTM!The down migration correctly reverses the up migration by dropping the default value.
Minor style nit: The up migration uses lowercase SQL keywords (
alter table) while this down migration uses uppercase (ALTER TABLE). Consider keeping consistent casing across migration pairs for readability.♻️ Optional: Consistent casing
-ALTER TABLE "public"."user_workflows" ALTER COLUMN "id" drop default; +alter table "public"."user_workflows" alter column "id" drop default;apps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yaml (1)
10-18: Consider removingidfrom insertable columns.Since the migration sets
idto default togen_random_uuid(), users don't need to (and shouldn't) provide this value. Removing it prevents potential conflicts or misuse.♻️ Suggested change for moderator role
columns: - provider - scopes - service - status - connected_at - revoked_at - - id - user_idApply the same change to the
userrole insert permission (lines 25-33).apps/web/services/hasura/hasura.service.ts (1)
2238-2266: Consider parameterizing provider and service for reusability.The function hardcodes
provider: 'google'andservice: 'gmail'. If you anticipate supporting other providers (e.g., Microsoft) or services (e.g., Drive, Calendar), consider accepting these as parameters similar toinsertN8nCredential.♻️ Suggested refactor for flexibility
export async function insertUserOAuthConnection( userId: string, scopes: string[], jwt: string, + provider: 'google' | 'microsoft' = 'google', + service: 'gmail' | 'drive' | 'calendar' = 'gmail', ) { if (!jwt) throw new Error('Authentication required to insert OAuth connection') const client = getHasuraClient({ jwt }) const result = await client.mutation({ insertUserOauthConnectionsOne: { __args: { object: { userId, - provider: 'google', - service: 'gmail', + provider, + service, scopes: scopes.join(' '), status: 'connected', connectedAt: new Date().toISOString(), }, }, id: true, }, }) return result.insertUserOauthConnectionsOne }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
packages/mb-genql/generated/schema.graphqlis excluded by!**/generated/**packages/mb-genql/generated/schema.tsis excluded by!**/generated/**packages/mb-genql/generated/types.tsis excluded by!**/generated/**
📒 Files selected for processing (24)
apps/hasura/metadata/databases/masterbots/tables/public_n8n_credentials.yamlapps/hasura/metadata/databases/masterbots/tables/public_user.yamlapps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yamlapps/hasura/metadata/databases/masterbots/tables/public_user_token.yamlapps/hasura/metadata/databases/masterbots/tables/public_user_workflows.yamlapps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/down.sqlapps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/up.sqlapps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/down.sqlapps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/up.sqlapps/hasura/migrations/masterbots/1768003836473_alter_table_public_user_oauth_connections_alter_column_revoked_at/down.sqlapps/hasura/migrations/masterbots/1768003836473_alter_table_public_user_oauth_connections_alter_column_revoked_at/up.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768100057144_alter_table_public_user_workflows_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768100057144_alter_table_public_user_workflows_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768100079972_alter_table_public_user_token_alter_column_user_id/down.sqlapps/hasura/migrations/masterbots/1768100079972_alter_table_public_user_token_alter_column_user_id/up.sqlapps/web/app/api/oauth/google/callback/route.tsapps/web/app/api/test-google-start/route.tsapps/web/auth.tsapps/web/lib/n8n.tsapps/web/services/hasura/hasura.service.ts
💤 Files with no reviewable changes (1)
- apps/hasura/metadata/databases/masterbots/tables/public_user.yaml
✅ Files skipped from review due to trivial changes (3)
- apps/hasura/migrations/masterbots/1768100079972_alter_table_public_user_token_alter_column_user_id/up.sql
- apps/hasura/metadata/databases/masterbots/tables/public_n8n_credentials.yaml
- apps/hasura/migrations/masterbots/1768003836473_alter_table_public_user_oauth_connections_alter_column_revoked_at/up.sql
🚧 Files skipped from review as they are similar to previous changes (3)
- apps/hasura/metadata/databases/masterbots/tables/public_user_workflows.yaml
- apps/web/app/api/oauth/google/callback/route.ts
- apps/web/lib/n8n.ts
🧰 Additional context used
📓 Path-based instructions (7)
apps/hasura/migrations/masterbots/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Store and manage Hasura migrations under apps/hasura/migrations/masterbots/
Store Hasura-managed migrations in timestamped folders under apps/hasura/migrations/masterbots/
Keep Hasura-managed database migrations in timestamped folders under apps/hasura/migrations/masterbots/
Files:
apps/hasura/migrations/masterbots/1768100057144_alter_table_public_user_workflows_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/up.sqlapps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/down.sqlapps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/down.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768100057144_alter_table_public_user_workflows_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/up.sqlapps/hasura/migrations/masterbots/1768100079972_alter_table_public_user_token_alter_column_user_id/down.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768003836473_alter_table_public_user_oauth_connections_alter_column_revoked_at/down.sql
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
**/*: Use lowercase with dash-separated directory and file names; use specific extensions: .config.ts, .test.ts, .context.tsx, .type.ts, .hook.ts; components may omit extension
Use Bun for package management and scripts instead of npm/yarn
Use Biome for formatting and linting via bun format-and-lint:fix; avoid Prettier/ESLint configs
Files:
apps/hasura/migrations/masterbots/1768100057144_alter_table_public_user_workflows_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/up.sqlapps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/down.sqlapps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/down.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/up.sqlapps/web/auth.tsapps/hasura/migrations/masterbots/1768100057144_alter_table_public_user_workflows_alter_column_id/up.sqlapps/hasura/metadata/databases/masterbots/tables/public_user_token.yamlapps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/up.sqlapps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yamlapps/hasura/migrations/masterbots/1768100079972_alter_table_public_user_token_alter_column_user_id/down.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/down.sqlapps/hasura/migrations/masterbots/1768003836473_alter_table_public_user_oauth_connections_alter_column_revoked_at/down.sqlapps/web/app/api/test-google-start/route.tsapps/web/services/hasura/hasura.service.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Use meaningful variable names; prefix booleans with is/has/does/should
Use interface for objects/classes; type for unions/tuples/aliases; enum for fixed sets; const for literals
Avoid any; prefer specific types
Leverage type inference where clear; annotate function params and return types
Prefer type assertions with 'as' over angle-bracket syntax
Use type guards to narrow types in conditionals
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Use modern JavaScript features with TypeScript across the codebase
Use meaningful names; prefix booleans with is/has/does/should (e.g., isDisabled)
Receive an object and return an object (RORO) for functions interfacing with external services
Type definitions: use interface for objects/classes; type for unions/tuples/aliases; const for literals; enum for fixed sets
Avoid any; prefer specific types
Leverage type inference; omit explicit annotations when obvious
Add explicit type annotations for function parameters and return values
Prefer type assertions with as over angle-bracket syntax
Use type guards to narrow types within conditionals
Favor composition over inheritance in code structure
**/*.{ts,tsx}: Avoid default exports; prefer named exports
Prefer RORO (Receive an object, return an object) for function signatures, especially for external service interactions
Use interface for object shapes/classes; type for unions/tuples/aliases; const for literals; enum for fixed enumerations
Avoid using any; prefer precise types
Leverage type inference when clear; omit redundant annotations
Explicitly annotate function parameters and return types
Prefer type assertions with as over angle-bracket syntax
Use type guards to narrow types safely
Use meaningful variable names; prefix booleans with is/has/does/should
Favor composition over inheritance
Use lowercase dash-separated names for files and folders; use extensions like .config.ts, .test.ts, .context.tsx, .typ...
Files:
apps/web/auth.tsapps/web/app/api/test-google-start/route.tsapps/web/services/hasura/hasura.service.ts
apps/{web,pro-web}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
apps/{web,pro-web}/**/*.{ts,tsx}: Use lowercase kebab-case for directories and filenames (components can omit extension)
Verify DOM operations and consider timing (RAF/delays) when manipulating the DOM in React
Use Tailwind CSS utility classes for styling React components
apps/{web,pro-web}/**/*.{ts,tsx}: Use TypeScript to define React props types (interfaces for props)
Use custom hooks (useMBChat, useThread, useSidebar, useModel) for domain-specific state and keep providers focused and composed hierarchically
Separate presentation from business logic and compose small components
Use hasura.service.ts for all GraphQL operations from UI layers
apps/{web,pro-web}/**/*.{ts,tsx}: Prefer Server Components; use the use client directive only when client-side features are required
Implement Nested Layouts using the App Router
Use Streaming and Suspense in Next.js 14/15 where appropriate
Follow Next.js file conventions as per documentation
Use IndexedDB for local caching to enable immediate UI updates
Files:
apps/web/auth.tsapps/web/app/api/test-google-start/route.tsapps/web/services/hasura/hasura.service.ts
apps/{web,pro-web}/app/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
apps/{web,pro-web}/app/**: Prefer Next.js Server Components; use 'use client' only when necessary
Leverage Streaming and Suspense for responsiveness in Next.js 15
Follow Next.js file conventions in the App Router
apps/{web,pro-web}/app/**: Leverage Server Components by default; use the use client directive only when client-side features are needed
Implement Nested Layouts using the App Router
Use Streaming and Suspense features in Next.js 14/15 where appropriate
Follow Next.js file conventions for routing and layout in the App Router
Optimize data fetching: fetch on the server, fetch where needed, and use preload patterns to avoid waterfalls
Files:
apps/web/app/api/test-google-start/route.ts
apps/{web,pro-web}/services/**
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Place external API integrations under services/
Files:
apps/web/services/hasura/hasura.service.ts
apps/{web,pro-web}/services/**/*.ts
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use RORO (Receive an object, Return an object) for functions, especially when calling external services
Place external API integrations under services/
Files:
apps/web/services/hasura/hasura.service.ts
🧠 Learnings (18)
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to apps/hasura/migrations/masterbots/** : Keep Hasura-managed database migrations in timestamped folders under apps/hasura/migrations/masterbots/
Applied to files:
apps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/up.sqlapps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/down.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768003836473_alter_table_public_user_oauth_connections_alter_column_revoked_at/down.sql
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Applies to apps/hasura/migrations/masterbots/** : Store Hasura-managed migrations in timestamped folders under apps/hasura/migrations/masterbots/
Applied to files:
apps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/up.sqlapps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/down.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/up.sql
📚 Learning: 2025-09-30T22:08:30.965Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-09-30T22:08:30.965Z
Learning: Applies to apps/hasura/migrations/masterbots/** : Store and manage Hasura migrations under apps/hasura/migrations/masterbots/
Applied to files:
apps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/up.sqlapps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/up.sql
📚 Learning: 2025-11-21T18:02:42.653Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 590
File: apps/web/lib/hooks/use-profile.tsx:79-81
Timestamp: 2025-11-21T18:02:42.653Z
Learning: Preference: In apps/web/lib/hooks/use-profile.tsx, avoid client-side re-fetching the current user in ProfileProvider. Initialize sessionUser from the server-provided NextAuth session (initialSession) and treat it as the source of truth; remove the useEffect that calls getUserByID. Persist client edits via NextAuth’s session update when needed.
Applied to files:
apps/web/auth.tsapps/web/app/api/test-google-start/route.ts
📚 Learning: 2025-11-28T03:44:16.389Z
Learnt from: sheriffjimoh
Repo: bitcashorg/masterbots PR: 590
File: apps/web/lib/hooks/use-profile.tsx:60-78
Timestamp: 2025-11-28T03:44:16.389Z
Learning: In apps/web/components/routes/preferences/preference-section.tsx: After updating user profile in the database via updateUserDetails, must call session.update() (from useSession hook) with the updated fields to trigger NextAuth's JWT callback with trigger='update'. This refreshes the JWT token and session automatically. Do not manually call updateSessionUser; the useEffect in use-profile.tsx will sync sessionUser from the refreshed session.user.
Applied to files:
apps/web/auth.ts
📚 Learning: 2025-11-21T18:00:08.455Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 590
File: apps/web/lib/hooks/use-profile.tsx:60-78
Timestamp: 2025-11-21T18:00:08.455Z
Learning: In apps/web/lib/hooks/use-profile.tsx: The sessionUser state should be populated directly from session.user (JWT) and not by fetching from Hasura on the client side. The useEffect should only synchronize sessionUser with session.user. Client-side Hasura fetches for user data should be avoided; user data comes from the JWT/session. Only when users update their profile should we refresh both the database and JWT token (via NextAuth session update trigger).
Applied to files:
apps/web/auth.tsapps/web/app/api/test-google-start/route.tsapps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Use NextAuth.js with custom user management; JWT for API auth; roles/subscriptions for access control
Applied to files:
apps/web/auth.tsapps/web/app/api/test-google-start/route.ts
📚 Learning: 2024-12-05T01:08:50.085Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 0
File: :0-0
Timestamp: 2024-12-05T01:08:50.085Z
Learning: The backend uses Hasura with proper table relationships, permissions, and metadata structure defined in YAML configurations.
Applied to files:
apps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yaml
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to apps/{web,pro-web}/**/ai-main-call.actions.{ts,tsx} : Route AI API handling through ai-main-call.actions for unified processing
Applied to files:
apps/web/app/api/test-google-start/route.ts
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to **/services/hasura.service.ts : Use hasura.service.ts as the single interaction point for GraphQL operations with Hasura
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:08:30.965Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-09-30T22:08:30.965Z
Learning: Applies to **/services/hasura.service.ts : Use hasura.service.ts as the single point for all GraphQL interactions
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Applies to apps/{web,pro-web}/**/*.{ts,tsx} : Use hasura.service.ts for all GraphQL operations from UI layers
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:09:37.969Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-09-30T22:09:37.969Z
Learning: Applies to apps/**/services/hasura.service.ts : Use hasura.service.ts as the single point of GraphQL interaction in each app
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-05-06T09:54:25.327Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 468
File: apps/masterbots.ai/app/api/cron/delete-requested-accounts/route.ts:70-81
Timestamp: 2025-05-06T09:54:25.327Z
Learning: For Hasura GraphQL operations in server-side code (including API routes and cron jobs), use the `getHasuraClient()` function from mb-lib rather than implementing custom fetch functions. This provides proper error handling, environment validation, and follows the established pattern in the codebase.
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-11-07T18:38:42.273Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 579
File: apps/pro-web/app/api/auth/signup/route.ts:151-157
Timestamp: 2025-11-07T18:38:42.273Z
Learning: In apps/pro-web/app/actions/admin.actions.ts, the insertUserOrganizations function should use Drizzle DB transactions to ensure atomicity when inserting organizations and their associated chatbots, preventing partial persistence issues.
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2024-11-14T21:12:19.789Z
Learnt from: AndlerRL
Repo: bitcashorg/masterbots PR: 302
File: apps/masterbots.ai/lib/hooks/use-mb-chat.ts:0-0
Timestamp: 2024-11-14T21:12:19.789Z
Learning: In `apps/masterbots.ai/lib/hooks/use-mb-chat.ts`, for handling message ordering issues, prefer simple solutions like using `setTimeout` over adding sequence numbers to the message schema, to keep the codebase simple.
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:08:30.965Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-09-30T22:08:30.965Z
Learning: Applies to apps/{web,pro-web}/services/**/*.ts : Use RORO (Receive an object, Return an object) for functions, especially when calling external services
Applied to files:
apps/web/services/hasura/hasura.service.ts
📚 Learning: 2025-09-30T22:11:18.270Z
Learnt from: CR
Repo: bitcashorg/masterbots PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-09-30T22:11:18.270Z
Learning: Applies to **/*.{ts,tsx} : Prefer RORO (Receive an object, return an object) for function signatures, especially for external service interactions
Applied to files:
apps/web/services/hasura/hasura.service.ts
🔇 Additional comments (12)
apps/hasura/migrations/masterbots/1768100057144_alter_table_public_user_workflows_alter_column_id/up.sql (1)
1-1: LGTM!The migration correctly sets
gen_random_uuid()as the default value for theidcolumn, ensuring newuser_workflowsrows automatically receive a UUID. This is a safe, non-blocking DDL operation.apps/hasura/migrations/masterbots/1768100079972_alter_table_public_user_token_alter_column_user_id/down.sql (1)
1-1: LGTM!The down migration correctly reverses the corresponding up migration by dropping the default value on
user_id.apps/hasura/metadata/databases/masterbots/tables/public_user_token.yaml (2)
11-29: Verify interaction between PostgreSQL default and Hasura check.The insert permissions correctly enforce that
user_idmust match the session user's ID. However, the corresponding up migration setsgen_random_uuid()as the default foruser_id.Since a random UUID won't match
X-Hasura-User-Id, clients must always explicitly provideuser_id— the PostgreSQL default becomes effectively unused for Hasura operations. Confirm this is intentional, or consider removing the default in the migration if it serves no purpose.
54-72: LGTM!The update permissions correctly restrict updates to only the
tokencolumn while enforcing row-level security viauser_idfilter. Preventinguser_idupdates is good security practice as it blocks ownership transfer.apps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/down.sql (1)
1-1: LGTM!The down migration correctly reverses the up migration by dropping the default value from the
idcolumn. This ensures clean rollback capability.apps/hasura/migrations/masterbots/1768099921973_alter_table_public_n8n_credentials_alter_column_id/up.sql (1)
1-1: Migration is missingCREATE EXTENSION IF NOT EXISTS pgcrypto;for consistency.The migration uses
gen_random_uuid()without explicitly creating the pgcrypto extension, unlike other similar migrations in the codebase that use the same function (e.g., 1726202691962_create_table_public_example/up.sql, 1703627082924_alter_table_public_thread_add_column_id/up.sql).Verify that pgcrypto is already initialized in the database or add
CREATE EXTENSION IF NOT EXISTS pgcrypto;before the ALTER statement to ensure consistency with established migration patterns.⛔ Skipped due to learnings
Learnt from: CR Repo: bitcashorg/masterbots PR: 0 File: AGENTS.md:0-0 Timestamp: 2025-09-30T22:11:18.270Z Learning: Applies to apps/hasura/migrations/masterbots/** : Keep Hasura-managed database migrations in timestamped folders under apps/hasura/migrations/masterbots/Learnt from: CR Repo: bitcashorg/masterbots PR: 0 File: CLAUDE.md:0-0 Timestamp: 2025-09-30T22:09:37.969Z Learning: Applies to apps/hasura/migrations/masterbots/** : Store Hasura-managed migrations in timestamped folders under apps/hasura/migrations/masterbots/Learnt from: CR Repo: bitcashorg/masterbots PR: 0 File: .github/copilot-instructions.md:0-0 Timestamp: 2025-09-30T22:08:30.965Z Learning: Applies to apps/hasura/migrations/masterbots/** : Store and manage Hasura migrations under apps/hasura/migrations/masterbots/apps/hasura/metadata/databases/masterbots/tables/public_user_oauth_connections.yaml (1)
35-92: LGTM on select and update permissions.Row-level security is properly enforced via
user_idfilter, and update permissions appropriately excludeid,user_id, andconnected_atfrom modifiable columns.apps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/up.sql (1)
1-1: LGTM!Using
gen_random_uuid()as the default for theidcolumn is the correct approach for auto-generating UUIDs in PostgreSQL 13+.Ensure the target PostgreSQL version is 13 or later, as
gen_random_uuid()is a built-in function starting from that version.apps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/down.sql (1)
1-1: LGTM!The down migration correctly reverses the up migration by dropping the default value on
connected_at.apps/hasura/migrations/masterbots/1768003504213_alter_table_public_user_oauth_connections_alter_column_id/down.sql (1)
1-1: LGTM!The down migration correctly reverses the up migration by dropping the UUID default on the
idcolumn.apps/hasura/migrations/masterbots/1768003794823_alter_table_public_user_oauth_connections_alter_column_connected_at/up.sql (1)
1-1: LGTM!Setting a default of
now()for theconnected_atcolumn is appropriate for automatically tracking when OAuth connections are established. This follows standard patterns for timestamp columns.apps/web/services/hasura/hasura.service.ts (1)
55-69: LGTM!The explicit parameter destructuring improves readability and makes the function signature clearer.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| alter table "public"."user_oauth_connections" drop constraint "user_oauth_connections_user_id_key"; | ||
| alter table "public"."user_oauth_connections" add constraint "user_oauth_connections_user_id_key" unique ("user_id"); |
There was a problem hiding this comment.
Down migration is identical to up migration — this is a no-op.
Both up.sql and down.sql contain the exact same statements: dropping and re-adding the same constraint with the same name on the same column. This means:
- The up migration performs no actual schema change (drops and immediately re-creates identical constraint)
- The down migration cannot rollback anything since it does the same operation
Either remove this migration entirely if no constraint change is needed, or fix the up/down pair to represent actual schema changes. If the intent was to add a new unique constraint, the down.sql should only drop the constraint:
Suggested fix if the intent is to add a unique constraint
down.sql should only drop the constraint:
alter table "public"."user_oauth_connections" drop constraint "user_oauth_connections_user_id_key";
-alter table "public"."user_oauth_connections" add constraint "user_oauth_connections_user_id_key" unique ("user_id");up.sql should only add the constraint:
-alter table "public"."user_oauth_connections" drop constraint "user_oauth_connections_user_id_key";
alter table "public"."user_oauth_connections" add constraint "user_oauth_connections_user_id_key" unique ("user_id");However, if the constraint already exists from the original table creation, this entire migration may be unnecessary.
📝 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.
| alter table "public"."user_oauth_connections" drop constraint "user_oauth_connections_user_id_key"; | |
| alter table "public"."user_oauth_connections" add constraint "user_oauth_connections_user_id_key" unique ("user_id"); | |
| alter table "public"."user_oauth_connections" drop constraint "user_oauth_connections_user_id_key"; |
🤖 Prompt for AI Agents
In
`@apps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/down.sql`
around lines 1 - 2, The down migration is identical to the up migration causing
a no-op; fix by ensuring up.sql and down.sql are complementary for the
constraint "user_oauth_connections_user_id_key" on table
"public"."user_oauth_connections": if the intent is to add a unique constraint,
make up.sql only add the constraint and make down.sql only drop the constraint
(DROP CONSTRAINT "user_oauth_connections_user_id_key"), or if the constraint
already exists remove this migration entirely; update the SQL files so up adds
and down removes the unique constraint (or delete the migration) and then re-run
migrations to verify correct behavior.
| alter table "public"."user_oauth_connections" drop constraint "user_oauth_connections_user_id_key"; | ||
| alter table "public"."user_oauth_connections" add constraint "user_oauth_connections_user_id_key" unique ("user_id"); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the structure and list the migration files
fd -t d "masterbots" apps/hasura/migrations/ | head -20Repository: bitcashorg/masterbots
Length of output: 99
🏁 Script executed:
# Find the specific migration file mentioned
cat apps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/up.sqlRepository: bitcashorg/masterbots
Length of output: 282
🏁 Script executed:
# Check the down.sql for this migration
cat apps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/down.sqlRepository: bitcashorg/masterbots
Length of output: 282
🏁 Script executed:
# Find the table creation migration for user_oauth_connections
fd -t f "up.sql" apps/hasura/migrations/masterbots | xargs grep -l "create table.*user_oauth_connections" 2>/dev/null | head -1 | xargs catRepository: bitcashorg/masterbots
Length of output: 47
🏁 Script executed:
# List all migrations in chronological order
fd -t d "masterbots" apps/hasura/migrations/ | sort | head -30Repository: bitcashorg/masterbots
Length of output: 99
🏁 Script executed:
# Search for user_oauth_connections table creation without case-sensitivity
fd -t f "up.sql" apps/hasura/migrations/masterbots | xargs grep -i "create.*user_oauth_connections" 2>/dev/null | head -5Repository: bitcashorg/masterbots
Length of output: 584
🏁 Script executed:
# Look for any mention of user_oauth_connections in migrations
fd -t f "up.sql" apps/hasura/migrations/masterbots | xargs grep -i "user_oauth_connections" 2>/dev/null | head -20Repository: bitcashorg/masterbots
Length of output: 1666
🏁 Script executed:
# Examine the down.sql more carefully - show with context
echo "=== UP.SQL ===" && cat apps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/up.sql && echo -e "\n=== DOWN.SQL ===" && cat apps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/down.sqlRepository: bitcashorg/masterbots
Length of output: 533
Migration is a no-op and the down migration is structurally broken.
The constraint user_oauth_connections_user_id_key already exists from the table creation migration (1766066591567), which includes UNIQUE ("user_id"). This migration drops and immediately re-creates it with the identical definition, causing:
- up.sql is redundant — drops and re-adds the same constraint, making no schema change
- down.sql is incorrect — it is identical to up.sql instead of reversing the change; down migrations should undo the up migration
This creates a bidirectional no-op migration. Either:
- Delete this migration entirely (if no schema change is needed), or
- If the intent was to rename the constraint or modify its definition, rewrite both up.sql and down.sql to reflect the actual change
🤖 Prompt for AI Agents
In
`@apps/hasura/migrations/masterbots/1768003427670_alter_table_public_user_oauth_connections_add_unique_user_id/up.sql`
around lines 1 - 2, The migration is a no-op and its down.sql is wrong: it drops
and re-adds the existing constraint "user_oauth_connections_user_id_key" (from
migration 1766066591567) then repeats the same in down.sql; either delete this
migration or implement a real change. Fix by either removing this migration file
pair entirely if no schema change is needed, or if you intended a rename or
change, modify up.sql to perform the actual change (e.g., rename constraint or
alter uniqueness) and update down.sql to reverse that change; reference the
constraint name "user_oauth_connections_user_id_key" and the migration id
1768003427670 when making the edits so both up.sql and down.sql are
complementary and no longer a bidirectional no-op.
| @@ -0,0 +1 @@ | |||
| alter table "public"."user_oauth_connections" alter column "revoked_at" set not null; | |||
There was a problem hiding this comment.
Down migration may fail if NULL values exist.
This rollback sets revoked_at to NOT NULL, but if the up migration was applied and rows were inserted with NULL in revoked_at (which is the expected state for active connections), this rollback will fail.
Consider adding a safe default or handling NULL values before applying the constraint:
♻️ Safer rollback approach
+-- Set a placeholder value for NULL entries before enforcing NOT NULL
+UPDATE "public"."user_oauth_connections" SET "revoked_at" = '1970-01-01 00:00:00' WHERE "revoked_at" IS NULL;
alter table "public"."user_oauth_connections" alter column "revoked_at" set not null;Note: The placeholder value approach may not be semantically correct for your domain. Alternatively, consider if this rollback is even necessary, or document that rollback requires manual data handling.
📝 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.
| alter table "public"."user_oauth_connections" alter column "revoked_at" set not null; | |
| -- Set a placeholder value for NULL entries before enforcing NOT NULL | |
| UPDATE "public"."user_oauth_connections" SET "revoked_at" = '1970-01-01 00:00:00' WHERE "revoked_at" IS NULL; | |
| alter table "public"."user_oauth_connections" alter column "revoked_at" set not null; |
🤖 Prompt for AI Agents
In
`@apps/hasura/migrations/masterbots/1768003836473_alter_table_public_user_oauth_connections_alter_column_revoked_at/down.sql`
at line 1, The down migration alters user_oauth_connections.revoked_at to NOT
NULL which will fail if any NULLs exist; before running ALTER TABLE
"user_oauth_connections" ALTER COLUMN "revoked_at" SET NOT NULL you must handle
existing NULL values (e.g. UPDATE user_oauth_connections SET revoked_at =
<safe_default_timestamp> WHERE revoked_at IS NULL, or DELETE/flag those rows, or
decide to skip/remove the NOT NULL change), or alternatively make the migration
idempotent by checking for NULLs and only applying the constraint when none
exist; update the down migration to perform the NULL-handling step(s) and
document the chosen semantic for revoked_at so rollback won't error.
| export async function insertUserWorkflow({ | ||
| userId, | ||
| workflowId, | ||
| workflowName, | ||
| service, | ||
| folderPath, | ||
| jwt, | ||
| }: { | ||
| userId: string | ||
| workflowId: string | ||
| workflowName: string | ||
| service: 'gmail' | 'drive' | ||
| folderPath: string | ||
| jwt: string | ||
| }) { | ||
| const client = getHasuraClient({ jwt }) | ||
| const result = await client.mutation({ | ||
| insertUserWorkflowsOne: { | ||
| __args: { | ||
| object: { | ||
| userId, | ||
| workflowId: workflowId, | ||
| workflowName: workflowName, | ||
| service, | ||
| folderPath: folderPath, | ||
| createdAt: new Date().toISOString(), | ||
| }, | ||
| }, | ||
| id: true, | ||
| }, | ||
| }) | ||
|
|
||
| return result.insertUserWorkflowsOne | ||
| } |
There was a problem hiding this comment.
Add JWT validation before database operation.
The function accepts jwt as a required parameter but doesn't validate it before calling getHasuraClient. Other functions in this file (e.g., getUserWorkflowByService at line 2339) throw an error if JWT is missing. This inconsistency could lead to confusing errors when the JWT is empty or undefined.
🔎 Proposed fix
export async function insertUserWorkflow({
userId,
workflowId,
workflowName,
service,
folderPath,
jwt,
}: {
userId: string
workflowId: string
workflowName: string
service: 'gmail' | 'drive'
folderPath: string
jwt: string
}) {
+ if (!jwt) throw new Error('Authentication required to insert user workflow')
const client = getHasuraClient({ jwt })🤖 Prompt for AI Agents
In `@apps/web/services/hasura/hasura.service.ts` around lines 2299 - 2332, The
insertUserWorkflow function should validate the jwt before calling
getHasuraClient: if jwt is falsy, throw the same error used by
getUserWorkflowByService (e.g., throw new Error('JWT is required') or match its
exact message) to maintain consistency; add this check at the start of
insertUserWorkflow (before getHasuraClient) so getHasuraClient is only called
with a valid token and the error behavior matches other functions in this file.
| return { | ||
| ...result.n8nCredentials[0], | ||
| n8n_credential_id: result.n8nCredentials[0].n8nCredentialId, | ||
| webhook_url: '', // Provide a default or fetch the actual value if available | ||
| } as UserCredential |
There was a problem hiding this comment.
Hardcoded empty webhook_url may cause issues for callers.
The function returns webhook_url: '' as a placeholder to satisfy the UserCredential type. This can mislead callers expecting a valid webhook URL. Consider either:
- Fetching
webhook_urlfrom the database if it exists - Defining a narrower return type that doesn't include
webhook_url - Making
webhook_urloptional in theUserCredentialtype
🤖 Prompt for AI Agents
In `@apps/web/services/hasura/hasura.service.ts` around lines 2386 - 2390, The
returned object includes a hardcoded empty webhook_url which can mislead
callers; update the code that builds the UserCredential (the return using
result.n8nCredentials[0] and casting to UserCredential) to either (a) retrieve
the real webhook URL from the DB result (e.g., include the webhook field from
result.n8nCredentials[0] or join the table that contains it) and set webhook_url
to that value, or (b) change the return type to a narrower interface that omits
webhook_url, or (c) make webhook_url optional on the UserCredential type and
omit it when not available—choose one approach and remove the hardcoded ''
placeholder so callers do not receive a false empty URL.
Summary by Sourcery
Introduce database and type support for user OAuth connections and n8n workflows while cleaning up unused organization/department structures and adjusting related metadata and permissions.
New Features:
Enhancements:
Deployment:
Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.