feat: add Sentry error capturing to schemaDesignTool #3731
Conversation
Wrap the schemaDesignTool function with withSentryCaptureException to automatically capture and report errors to Sentry. This enables monitoring of DDL generation errors, schema retrieval errors, patch operation errors, and version creation errors. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
|
|
Finished running flow.
|
|
Updates to Preview Branch (fix-db-agent-tool-use) ↗︎
Tasks are run on every commit but only new migration files are pushed.
View logs for this Workflow Run ↗︎. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Check changeset necessityStatus:
Reason:
Changeset (copy & paste):---
# No changeset required for this PR (only @liam-hq/agent, which is ignored)
---
- ♻️ No versioned packages changed; internal agent tooling and workflow updates only.
- Add Sentry error capturing to schemaDesignTool and improve workflow routing in @liam-hq/agent |
MH4GF
changed the title
MH4GF
changed the title
🤖 Agent Deep Modeling ExecutionStarted at: 2025-10-09 10:12:07 UTC Command Output
RUN v3.2.4 /home/runner/work/liam/liam/frontend/internal-packages/agent (node:7607) ExperimentalWarning: WASI is an experimental feature and might change at any time ✅ [INFO] 2025-10-09T10:12:09.616Z 🧠 Thinking (pm)... Producing user management requirements I need to act as the PM Agent to create BRD-like requirements for the user's request about designing a simple user management system. It seems that there’s no initial schema provided, so I’m making some assumptions. First, I’ll create a concise checklist of 3–7 key tasks. I plan to structure everything into the BRD format and later save the analyzed requirements. Since external information isn't necessary, I can proceed without using any web searches. Structuring the BRD My BRD will include various components like business requirements, functional needs, non-functional requirements, and more such as data validation rules, roles and permissions, workflows, and privacy compliance. I need to prepare the analyzed requirements to save as "goal" and "testcases" using the appropriate tool. Along with the tool call, I have to present the BRD in the response and ensure that each testcase covers user accounts, authentication, and other categories while being business-focused with positive and negative scenarios. Finally, I have to confirm the successful save. Assembling the BRD I need to create 6-12 test cases across various categories. It's vital that I perform the tool call only after I've analyzed and structured everything. Before calling the "saveRequirementsToArtifactTool," I have to include a single line stating the "purpose + minimal inputs." The tool is for saving requirements as an artifact, which accepts business and functional requirements. I’ll combine that with a preface line, something like: "Purpose: Save analyzed BRD requirements as an artifact; Inputs: goal summary, categorized test cases." Now, I'll assemble the BRD structure, which includes checklist bullets, an executive summary, scope, and the defined personas and roles. Creating BRD essentials I want to keep this simple while outlining the high-level business requirements, which will consist of 8-12 bullet points. Next, I'll break down the functional requirements by feature, covering aspects like User Registration, Authentication, Password Management, Role-Based Access Control, User Profile Management, and more. For the Data Model Requirements, I'll define the entities and attributes for tables like users and roles, ensuring to include core fields and considering optional permissions for future extensibility. But I want to keep the structure straightforward, using base roles for simplicity. Crafting authorization and data model requirements I’m focusing on the authorization and roles aspect now, detailing functions like assigning roles and preventing non-existent role assignments. I’ll also specify checks such as ensuring a Manager can’t access Admin-only functions and that disabled users can’t log in. I’ll create cases for password resets and maintaining an audit log for user role changes. Additionally, I'll include data retrieval processes for listing and searching users, ensuring constraints to prevent duplicate role assignments. Now, I need to finalize the BRD structure by compiling sections in a checklist format, defining the purpose and inputs, and preparing for the tool call while avoiding heavy formatting. ⏺ (pm): Checklist
Business Requirements Document (BRD): Simple User Management System
Acceptance Test Cases (business-focused with SQL operation types)
Purpose: Save analyzed BRD goal and categorized SQL test cases as an artifact; Inputs: goal summary and structured testcases {"goal":"Define clear, production-ready business and functional requirements for a simple, secure user management system with authentication, role-based access, user lifecycle management, and auditability.","testcases":{"User Registration and Profile":[{"title":"Admin creates a new user with required fields successfully","type":"INSERT"},{"title":"Prevent creating a user with duplicate email","type":"INSERT"},{"title":"Self-registration creates a pending verification user","type":"INSERT"},{"title":"User updates own profile name and phone successfully","type":"UPDATE"},{"title":"Reject profile update with invalid phone format","type":"UPDATE"},{"title":"Admin soft-deletes a user account and user no longer appears in active lists","type":"DELETE"}],"Authentication and Sessions":[{"title":"User logs in with valid credentials and receives a session/token","type":"SELECT"},{"title":"Reject login with incorrect password","type":"SELECT"},{"title":"Reject login for unverified email when verification is required","type":"SELECT"},{"title":"Logout revokes the active session/token","type":"DELETE"}],"Authorization and Roles":[{"title":"Admin assigns the Manager role to a user","type":"INSERT"},{"title":"Prevent assigning a non-existent role to a user","type":"INSERT"},{"title":"Prevent duplicate role assignment to the same user","type":"INSERT"},{"title":"Admin changes a user’s roles successfully","type":"UPDATE"},{"title":"Manager cannot access Admin-only user deletion","type":"SELECT"}],"Account Status and Security":[{"title":"Admin disables a user; disabled user cannot log in","type":"UPDATE"},{"title":"Admin enables a disabled user; user can log in again","type":"UPDATE"},{"title":"Password reset request creates a reset token","type":"INSERT"},{"title":"Reject password reset using an expired token","type":"SELECT"},{"title":"Enforce password complexity when changing password","type":"UPDATE"}],"Audit and Compliance":[{"title":"Audit log created for role assignment event","type":"INSERT"},{"title":"Retrieve audit trail entries for a specific user","type":"SELECT"}],"Data Retrieval and Search":[{"title":"List users filtered by status with pagination returns expected results","type":"SELECT"},{"title":"Search by email prefix returns matching users only","type":"SELECT"},{"title":"Export filtered user list within limits succeeds","type":"SELECT"}]}} 🧠 Thinking (pm)... Finalizing test case structure I don’t think we need to use web search here since we're dealing with standard practices. The schema structure is empty, indicating a greenfield design. I’ll focus on creating acceptance test case categories like we did previously. It’s crucial to ensure that "type" utilizes SQL operations. We should save our analyzed requirements, with the tool expecting a structured object. I’ll revise our categories for coverage and consider adding a "Data Validation" category as we finalize this. Preparing requirements for analysis I’m set to use that exact one-liner and follow it up with the tool. After calling the tool, I'll need to confirm success, saying something like, "Saved successfully." If the tool returns "any," I’ll assume it was successful and state, "Artifact saved." It’s important to keep the content concise, despite the length of a Business Requirements Document (BRD). I’ll use structured bullet sections with slight improvements while avoiding heavy formatting. I’ll also ensure I work autonomously without asking questions or needing user dialogue. Structuring the requirements I need to make sure the requirements are prepared so the DB Agent can handle database design effectively, and the QA Agent can confirm that the design meets those requirements. The Business Requirements Document (BRD) will include data model requirements and acceptance test cases, which is great. Even though the current schema structure is empty, I’ll proceed. I’ll start with a checklist of 5-6 bullet points, followed by sections for the Simple User Management System, outlining goals, scope, assumptions, roles, business and functional requirements, data model needs, validation, non-functional aspects, key workflows, reporting, security, and acceptance test cases. Structuring acceptance test cases I need to organize the acceptance test cases so they can be saved in the tool call later. I’ll include them in the document and then call the tool with the same set of test cases. I plan to reuse earlier acceptance tests to save time. It’s crucial to ensure that the operation types are in uppercase. After that, I’ll prepare the one-liner for the tool call, using functions.saveRequirementsToArtifactTool with the goal string and test cases object. The goal will define clear requirements for a secure user management system. Let's produce this! ⏺ (pm): Purpose: Save analyzed BRD goal and categorized SQL test cases as an artifact; Inputs: goal summary and structured testcases 🔧 saveRequirementsToArtifactTool() ⎿ unknown: Requirements saved successfully to artifact 🧠 Thinking (db)... Designing database tables I need to start with a planning checklist that includes about 3 to 7 bullet points. Then, I should utilize the schema design tool to prepare operations for adding tables: users, roles, user_roles, sessions, password_resets, and audit_logs. It's important to outline constraints, indexes, and comments along with the purpose and minimal inputs before making the tool call. Afterward, I’ll validate the results briefly and report confirmation related to the requirements. I'll construct JSON operations for these multiple tables. Implementing indexes and constraints I need to focus on creating indexes for fields like email, phone, status, and role names. I'll ensure each table has the right constraints, including primary and foreign keys. Next, I'll call the schema design tool with the operations array to execute these changes. After the call, I'll validate the success of the operation, even if I can’t see the result directly. I’ll confirm that everything is validated and clearly map it to the requirements before wrapping things up. 🔧 schemaDesignTool() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() ⏺ (qa): { 🔧 saveTestcase(): User Registration and Profile\n-- Title: User updates own profile name and phone successfully\n-- Type: UPDATE\n\n-- Preconditions (example data to ensure the UPDATE can execute):\n-- 1) A user exists with a known uuid, active status, and permissions to update profile.\n-- 2) The users table enforces NOT NULL on id, email, status, disabled, created_at, updated_at, is_verified, profile_completed.\n-- 3) Email uniqueness ⏺ (qa): { 🔧 saveTestcase() 🔧 saveTestcase()\n-- Title: Reject password reset using an expired token\n-- Type: SELECT\n\n-- - name: new display name\n-- - phone: new E.164 formatted phone\n-- - updated_at: current timestamp\n-- The operation should only affect the 🔧 saveTestcase() Assumptions based on schema:\n-- - password_resets stores reset tokens with expires_at and used flag\n-- targeted user and should not alter other fields.\n\n-- Assumptions:\n-- - The application passes the user's UUID as :user_id - A reset is valid only if: used = false AND expires_at > now()\n-- - We return a result indicating invalid/valid status along with relevant tokens\n\n-- Sample query: identify tokens that would be considered (placeholder), and the new values as :new_name and :new_phone.\n-- - We rely on now() at the database side for updated_at to reflect the update time.\n-- - The operation should fail if the user does not exist or is not updatable (e.g., 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() invalid due to expiration or prior use\nWITH valid_tokens AS (\n SELECT\n pr.id AS reset_id,\n pr.user_id,\n pr.created_at,\n pr.expires_at,\n pr.used,\n pr.used_at,\n CASE\n WHEN pr.used = TRUE THEN 'invalid_used'\n WHEN pr.expires_at <= NOW() THEN 'invalid_expired'\n ELSE 'valid'\n END AS status\n FROM password_resets pr\n)\nSELECT\n vt.reset_id,\n vt.user_id,\n vt.created_at,\ deleted or disabled).\n\n-- Note: Use gen_random_uuid() only for inserting new rows; here we are updating existing row.\n\nWITH target AS (\n SELECT u.id\n FROM users u\n WHERE u.id = :user_id\n AND u.status = 'active'\n AND u.deleted_at IS NULL\n AND u.disabled = FALSE\n)\nUPDATE users u\nSET\n name = COALESCE(:new_name, u.name),\n phone = COALESCE(:new 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase()n vt.expires_at,\n vt.used,\n vt.used_at,\n vt.status\nFROM valid_tokens vt\nWHERE vt.status <> 'valid'\nORDER BY vt.expires_at ASC NULLS LAST;\n\n-- Expected behavior:\n-- - Rows with status 'invalid_expired' represent tokens that cannot be used because they are expired.\n-- - Rows with status 'invalid_used' represent tokens that have already been consumed.\n-- - Rows with status 'valid' would be eligible for use; this SELECT intentionally excludes them.\n", 🔧 saveTestcase()(node:7607) Warning: The 'import-in-the-middle' hook has already been initialized 🔧 saveTestcase() 🔧 saveTestcase() ⏺ (qa):
{ 🔧 saveTestcase() ⏺ (qa): { ⏺ (qa): { ⏺ (qa): { 🔧 saveTestcase()(node:7607) Warning: The 'import-in-the-middle' hook has already been initialized ❌ Test Case: Admin soft-deletes a user account and user no longer appears in active listsError:
|
MH4GF
requested review from
NoritakaIkeda,
junkisai and
sasamuku
and removed request for
a team
MH4GF
changed the title
2 participants
Summary
Add Sentry error capturing to
schemaDesignToolby wrapping the tool function withwithSentryCaptureException. This enables automatic error reporting for all errors that occur within the tool, including:Changes
withSentryCaptureExceptionutilitywithSentryCaptureExceptionImplementation
Following the same pattern used in
saveTestcaseTool, the tool function is wrapped withwithSentryCaptureExceptionwhich:Test Plan
🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com