fix(deps): update dependency @electric-sql/pglite to v0.3.11 #3963
Conversation
renovate
bot
requested review from
MH4GF,
NoritakaIkeda,
junkisai and
sasamuku
and removed request for
a team
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
Finished running flow.
|
||||||||||||
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the Comment |
Check changeset necessityStatus: NOT REQUIRED Reason:
Changeset (copy & paste):N/A – No changes to @liam-hq/cli, @liam-hq/erd-core, @liam-hq/schema, or @liam-hq/ui; a changeset is not required. |
🤖 Agent Deep Modeling ExecutionProcessing time: 4m 25s View DetailsCommand Output
RUN v3.2.4 /home/runner/work/liam/liam/frontend/internal-packages/agent (node:7628) ExperimentalWarning: WASI is an experimental feature and might change at any time ✅ [INFO] 2025-11-04T02:49:43.920Z 🧠 Thinking (pm)... Designing user management system I need to act like a Project Management Agent since the user wants me to design a simple user management system. My first step is to create structured requirements in a BRD-like format, including test cases. Then, I’ll use the processAnalyzedRequirementsTool to save these requirements. There’s no dialogue here; it's all about working autonomously. I need to produce a concise checklist of tasks, then analyze and structure everything into the BRD format while ensuring that the final output works correctly with the tool. Structuring the user management system In similar tasks, I've found that a comprehensive BRD usually includes sections like Overview, Scope, and Functional Requirements, along with others. After that, I produce test case categories with various scenarios, ensuring the tool captures both positive and negative cases. For this user management system, I'll focus on critical components like user registration, login, and password reset. I also need to ensure I provide sufficient details for the Database Agent and QA Agent to do their jobs well, while keeping it straightforward. Defining the database structure I’ll include core tables like users, roles, user_roles, and others, while considering if I should simplify by omitting sessions and auth tokens. The test cases need to focus on SQL types, aimed at verifying the database design. I’ll also define necessary constraints, like unique emails and password hash not null. Enums will cover user statuses and roles. Since the current schema is empty, I’ll make assumptions to fill the gaps. I’ll start by creating a checklist, then the BRD, and finally structure the test cases. Crafting the BRD I need to focus on business-oriented titles, where types are defined as SQL operations. The goal here is to create a simple user management system with features like registration, login, profile management, and email verification. The scope includes managing user accounts and roles, while excluding things like SSO and multi-factor authentication. I’ll identify user personas such as End User and Admin. Then, I’ll outline functional requirements, like unique email registration and a password policy, along with email verification mechanisms and profile management features. Detailing roles and data model I'm defining roles and permissions, with a default "user" role and a comprehensive account status system, including active and suspended states. For password resets, I’ll track tokens, and log CRUD actions for audit purposes. I need to specify fields for the users, roles, and related tables in the data model. Constraints will ensure email uniqueness and enforce password policies. I’ll also outline test case categories for various functionalities, focusing on business-oriented titles mapped to SQL operations. These will help verify that the database design meets our requirements without unnecessary complexity. Defining audit logging and test cases I’m examining how to handle soft deletes; we’ll use UPDATE rather than DELETE, but we could note a negative case for hard deletes. For audit logging, I can specify that an audit row is created when a user is added, marked with INSERT. I need to set clear data model requirements with minimal tables like users and roles. Regarding email uniqueness and case insensitivity, I’ll require the use of the Defining data integrity and BRD structure I’ve been reviewing data integrity for our user management system. I need to ensure foreign key constraints prevent assigning roles to non-existent users and require soft deletes to maintain user roles. In my BRD structure, I’ll present sections like an overview, scope, personas, and functional requirements. I’ll outline test scenario categories focusing on registration, email verification, authentication, profile management, and more, ensuring each test case is structured correctly. I want to keep the content concise but clear about how email normalization should be enforced, and ensure unique case-insensitivity for emails during registration. Finalizing this will involve preparing test cases that logically cover each area appropriately. Documenting authentication, profiles, and roles In the authentication category, I'm focusing on ensuring successful logins for active, verified users and blocking access for those pending verification or suspended. I'll also record the last login timestamp. When managing profiles, I plan to allow updates for full names and phone numbers, rejecting invalid formats. For role management, default user roles will be assigned, and I'll prevent duplicate role assignments. For password resets, I'll create tokens and control their validity. In terms of soft deletes, I'll address user status changes while allowing re-registration after deletion. I'll include data integrity checks to maintain referential integrity among roles. Now, I’ll save these analyzed requirements and move on to the tool call! ⏺ (pm): Saving analyzed requirements: goal + testcase categories and titles with SQL types for a simple user management system. 🔧 processAnalyzedRequirementsTool() ⎿ processAnalyzedRequirementsTool: Requirements processed and streamed successfully 🧠 Thinking (db)... Planning table structure I'm planning to use a tool to create tables. I need to specify the purpose and minimal inputs before making the tool call. The required tables include users, roles, user_roles, email_verifications, and password_resets, each with specific columns, constraints, and indexes. I’ll ensure that email addresses are stored in a normalized format. To keep it unique and case-insensitive, I'll focus on managing the email_normalized column carefully. There’s a lot to think through with triggers, checks, and unique constraints. That'll be a design challenge! Designing email uniqueness I'm considering adding a deleted_at timestamp and a unique index on (email_normalized, deleted_at). However, uniqueness for a null deleted_at might pose a challenge. An alternative could be a boolean is_deleted, but soft-deletion with deleted_at is preferred. I want to ensure that re-registering after a soft-delete is possible while also preventing duplicate active emails, regardless of case. Unfortunately, partial indexes aren't supported, and using deleted_at in the key could allow duplicates. I really need to find the right balance here! Resolving email conflicts I’m realizing that if an existing active record has a deleted_at of null, a new insert with a deleted_at also set to null would cause a conflict because both are treated as equal. In SQL, unique indexes typically consider multiple nulls acceptable, which causes an issue in PostgreSQL since they treat nulls as unequal. So, I think a better approach might be to use a boolean is_deleted set to false for active records. This ensures uniqueness among active emails while allowing for soft-deletion when is_deleted is true. I also want to implement various constraints and keys. It’s quite a puzzle! Preparing table migration I'm considering an alternative where I add an expires_at column along with a used boolean to manage active tokens better. To prevent a second active token, I can add a unique constraint on (user_id, used), which would indeed stop duplicates for the same user_id and used=false. This same logic applies to the password_resets table. Now I'll create the necessary constraints and indexes. It's time to prepare my tool call using functions.createMigrationTool for adding the tables with the appropriate columns and types—let’s get the JSON crafted! ⏺ (db): Purpose: Create schema for a user management system — adding tables users, roles, user_roles, email_verifications, password_resets with columns, indexes, and constraints. Minimal inputs: table names, columns (types, notNull, defaults, comments), primary/foreign keys, unique indexes. I'll now apply the migration to add these tables. 🔧 createMigrationTool() ⎿ createMigrationTool: Schema successfully updated. The operations have been applied to the database schema, DDL validation successful (63/63 statements executed successfully), and new version created. ⏺ (db): Operation performed: Added tables users, roles, user_roles, email_verifications, and password_resets with columns, indexes, and constraints as specified. Minimal inputs: table definitions (names, columns, comments), indexes, PKs, and FKs. Validation: Migration applied successfully; DDL executed (63 statements) with no errors. Summary of key schema elements (verifiable against BRD requirements):
Next steps I executed per instructions: schema created and validated. If you want, I can now:
Which of those would you like me to produce next? 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() ⎿ saveTestcase: Successfully saved SQL for test case "Reject creation of duplicate role keys" in category "Data Integrity & Constraints" 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() 🔧 saveTestcase() ⎿ saveTestcase: Successfully saved SQL for test case "Prevent assigning a non-existent role to a user (FK constraint)" in category "Data Integrity & Constraints" ⎿ saveTestcase: Successfully saved SQL for test case "Assign admin role to a user" in category "Role Management" ⎿ saveTestcase: Successfully saved SQL for test case "Reject registration when email already exists regardless of case" in category "Registration & Email" ⎿ saveTestcase: Successfully saved SQL for test case "Record last_login_at on successful login" in category "Authentication & Account Status" ⎿ saveTestcase: Successfully saved SQL for test case "updated_at auto-updates on profile change" in category "Profile Management" 🔧 saveTestcase() ⎿ saveTestcase: Successfully saved SQL for test case "Create password reset token for an existing user" in category "Password Reset" ⎿ saveTestcase: Successfully saved SQL for test case "Create an email verification token for a newly registered user" in category "Email Verification" ⎿ saveTestcase: Successfully saved SQL for test case "Reject creating a second active email verification token for the same user" in category "Data Integrity & Constraints" ⎿ saveTestcase: Successfully saved SQL for test case "Prevent assigning a role to a non-existent user (FK constraint)" in category "Data Integrity & Constraints" ⎿ saveTestcase: Successfully saved SQL for test case "Create new user with a unique email succeeds" in category "Registration & Email" ⎿ saveTestcase: Successfully saved SQL for test case "Reset password with valid, unexpired token updates password_hash and marks token used" in category "Password Reset" ⎿ saveTestcase: Successfully saved SQL for test case "Update full_name and phone for an active user" in category "Profile Management" ⎿ saveTestcase: Successfully saved SQL for test case "Email is stored and returned in normalized (case-insensitive unique) form" in category "Registration & Email" ⎿ saveTestcase: Successfully saved SQL for test case "New user defaults to pending verification status with timestamps set" in category "Registration & Email" ⎿ saveTestcase: Successfully saved SQL for test case "Verify email with valid, unexpired token sets email_verified_at and activates account" in category "Email Verification" ⎿ saveTestcase: Successfully saved SQL for test case "Reject registration missing required fields (email, password_hash, full_name)" in category "Registration & Email" ⎿ saveTestcase: Successfully saved SQL for test case "Change password updates password_hash and password_changed_at" in category "Profile Management" ⎿ saveTestcase: Successfully saved SQL for test case "Allow re-registering the same email after soft-delete" in category "Soft Delete" ⎿ saveTestcase: Successfully saved SQL for test case "Reject password reset using already used token" in category "Password Reset" ⎿ saveTestcase: Successfully saved SQL for test case "Block login for suspended user" in category "Authentication & Account Status" ⎿ saveTestcase: Successfully saved SQL for test case "Reject password reset using expired token" in category "Password Reset" ⎿ saveTestcase: Successfully saved SQL for test case "Soft-delete a user sets deleted_at and status to deactivated" in category "Soft Delete" ⎿ saveTestcase: Successfully saved SQL for test case "Prevent duplicate role assignment for the same user and role" in category "Role Management" ⎿ saveTestcase: Successfully saved SQL for test case "Prevent login for soft-deleted users" in category "Soft Delete" ⎿ saveTestcase: Successfully saved SQL for test case "Block login for user pending email verification" in category "Authentication & Account Status" ⎿ saveTestcase: Successfully saved SQL for test case "New user has default role of user assigned" in category "Role Management" ⎿ saveTestcase: Successfully saved SQL for test case "Deleting a role cascades to user_roles mappings" in category "Data Integrity & Constraints" 🔧 saveTestcase() ⎿ saveTestcase: Successfully saved SQL for test case "Reject verification when token is expired" in category "Email Verification" ⎿ saveTestcase: Successfully saved SQL for test case "Revoke a role from a user" in category "Role Management" ⎿ saveTestcase: Successfully saved SQL for test case "Select users by role returns only users with that role" in category "Role Management" ⎿ saveTestcase: Successfully saved SQL for test case "Successful login reads an active and verified user by email" in category "Authentication & Account Status" 🔧 saveTestcase() ⎿ saveTestcase: Successfully saved SQL for test case "Reject verification when token is already used" in category "Email Verification" ⎿ runTestTool: 24/34 test cases passed, 10 failed ❌ Test Case: Create new user with a unique email succeedsError: `1 test(s) failed:Test 4: is_deleted should be false by default SELECT lives_ok($$INSERT INTO users (email, full_name, password_hash, email_normalized) VALUES ('TestUser+1@Example.COM', 'Test User', 'hashed_pw', lower(trim('TestUser+1@Example.COM')))$$, 'Should insert a new user with normalized email');
SELECT is((SELECT COUNT(*) FROM users WHERE email_normalized = lower(trim('TestUser+1@Example.COM'))), 1::bigint, 'Normalized email should exist once');
SELECT is((SELECT email FROM users WHERE email_normalized = lower(trim('TestUser+1@Example.COM'))), 'TestUser+1@Example.COM'::text, 'Stored original email preserved');
SELECT ok((SELECT is_deleted FROM users WHERE email_normalized = lower(trim('TestUser+1@Example.COM'))), 'is_deleted should be false by default');
SELECT ok((SELECT status = 'pending' FROM users WHERE email_normalized = lower(trim('TestUser+1@Example.COM'))), 'Default status should be pending');❌ Test Case: Email is stored and returned in normalized (case-insensitive unique) formError: `1 test(s) failed:Test 7: threw 23505 SELECT lives_ok($$INSERT INTO users (email, email_normalized, full_name, password_hash) VALUES ('User+Test@Example.COM', lower(trim('User+Test@Example.COM')), 'User Test', 'passhash')$$, 'Setup: insert user with mixed-case email');
SELECT is((SELECT email_normalized::text FROM users WHERE email = 'User+Test@Example.COM'), 'user+test@example.com'::text, 'email_normalized should be lowercased and trimmed');
SELECT is((SELECT COUNT(*) FROM users WHERE email_normalized = 'user+test@example.com'), 1::bigint, 'Normalized email should be queryable and unique count equals 1');
SELECT lives_ok($$INSERT INTO users (email, email_normalized, full_name, password_hash) VALUES ('Another <duplicate>@Example.com', lower(trim('ANOTHER <DUPLICATE>@Example.com')), 'Another', 'passhash2')$$, 'Setup: insert second distinct user');
SELECT is((SELECT email_normalized::text FROM users WHERE email = 'Another <duplicate>@Example.com'), 'another <duplicate>@example.com'::text, 'second email normalized correctly');
SELECT results_eq($$SELECT email_normalized::text FROM users ORDER BY email_normalized$$, $$VALUES ('another <duplicate>@example.com'), ('user+test@example.com')$$, 'Should return normalized emails in order');
SELECT throws_ok($$INSERT INTO users (email, email_normalized, full_name, password_hash) VALUES ('dup@Example.com', lower(trim('DUP@example.com')), 'Dup', 'pass')$$, '23505' );
❌ Test Case: Create an email verification token for a newly registered userError: `1 test(s) failed:Test 4: Newly created token should be unused (false) SELECT lives_ok($$INSERT INTO users (email, full_name, password_hash, email_normalized) VALUES ('Test@Example.COM', 'Test User', 'hash', lower(trim('Test@Example.COM')))$$, 'Setup: insert new user');
SELECT lives_ok($$INSERT INTO email_verifications (user_id, token_hash) VALUES ((SELECT id FROM users WHERE email = 'Test@Example.COM'), 'tokenhash123')$$, 'Should create email verification token for newly registered user');
SELECT is((SELECT COUNT(*) FROM email_verifications WHERE user_id = (SELECT id FROM users WHERE email = 'Test@Example.COM')), 1::bigint, 'There should be exactly one email_verification for the user');
SELECT ok((SELECT used FROM email_verifications WHERE user_id = (SELECT id FROM users WHERE email = 'Test@Example.COM')), 'Newly created token should be unused (false)');
SELECT ok((SELECT expires_at > created_at FROM email_verifications WHERE user_id = (SELECT id FROM users WHERE email = 'Test@Example.COM')), 'Token expires_at should be after created_at');
SELECT throws_ok($$INSERT INTO email_verifications (user_id, used, token_hash) VALUES ((SELECT id FROM users WHERE email = 'Test@Example.COM'), false, 'anotherhash')$$, '23505');❌ Test Case: Reject verification when token is expiredError: `1 test(s) failed:Test 3: threw 23514 SELECT lives_ok($$INSERT INTO users (email, full_name, password_hash, email_normalized) VALUES ('expired@example.com', 'Expired User', 'pw', lower('expired@example.com'))$$, 'Setup: insert user');
SELECT lives_ok($$INSERT INTO email_verifications (user_id, token_hash, expires_at) VALUES ((SELECT id FROM users WHERE email = 'expired@example.com'), 'hash123', NOW() - INTERVAL '1 hour')$$, 'Setup: insert expired token');
SELECT throws_ok($$UPDATE email_verifications SET used = true WHERE id = (SELECT id FROM email_verifications WHERE token_hash = 'hash123') AND expires_at > NOW()$$, '23514');
SELECT lives_ok($$UPDATE email_verifications SET used = true WHERE id = (SELECT id FROM email_verifications WHERE token_hash = 'hash123' AND expires_at > NOW())$$, 'Attempt update with condition (no rows) should succeed as no-op');
SELECT is((SELECT used FROM email_verifications WHERE token_hash = 'hash123'), false, 'Expired token should remain unused');❌ Test Case: Reject verification when token is already usedError:
|
renovate
bot
force-pushed
the
renovate/electric-sql-pglite-0.x
branch
from
2ac618f to
2bd1902
Compare
junkisai
left a comment
junkisai
left a comment
There was a problem hiding this comment.
✅ Approved: Safe patch update
Version: 0.3.10 → 0.3.11 (patch)
Type: Feature addition (PostgreSQL extensions)
Risk: Low
Changes:
- Added PostgreSQL contrib extensions: dict_int, dict_xsyn, file_fdw, intarray, pageinspect, pg_buffercache, pg_freespacemap, pg_surgery, pg_visibility, pg_walinspect, unaccent
- No breaking changes
- No security fixes
- All CI checks passed
Decision: This is a safe enhancement-only patch release with no impact on core functionality.
This PR contains the following updates:
0.3.10->0.3.11Release Notes
electric-sql/pglite (@electric-sql/pglite)
v0.3.11Compare Source
Patch Changes
9a104b9: Added dict_int, dict_xsyn, file_fdw, intarray, pageinspect, pg_buffercache, pg_freespacemap, pg_surgery, pg_visibility, pg_walinspect, unaccent contrib extensionsConfiguration
📅 Schedule: Branch creation - Only on Sunday and Saturday ( * * * * 0,6 ) (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.