fix: Add test user to backend test setup to satisfy foreign key const…

[marcodejongh]

…raint

The session-persistence tests use 'user-123' as the userId for createDiscoverableSession, but the board_sessions.created_by_user_id column has a foreign key constraint referencing the users table.

This fix:

• Truncates the users table in beforeEach to ensure clean state
• Creates the 'user-123' test user before each test

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
boardsesh	Ready	Preview, Comment	Jan 1, 2026 4:40am

[claude]

Claude Review

No issues found.

The fix correctly addresses the foreign key constraint issue by:

1. Truncating the users table in the proper order (after dependent tables)
2. Creating the required test user before tests that reference it

The ON CONFLICT DO NOTHING is appropriate for test setup idempotency.

[claude]

Claude Review

No significant issues found.

The fix correctly addresses the foreign key constraint violation by:

1. Truncating the users table in beforeEach
2. Creating the 'user-123' test user before tests run
3. Using sharedDb for consistency with roomManager

Minor note: The ON CONFLICT (id) DO NOTHING clause is unnecessary since the table is truncated immediately before, but it's harmless.

[claude]

Claude Review

Issues Found

1. Schema drift in test table definitions (packages/backend/src/__tests__/setup.ts:75-155): The kilter_climbs and tension_climbs test tables are missing columns present in the actual schema:

   • Missing angle column
   • Missing synced column

   This may cause tests to pass against an incomplete schema while failing against the real database.

2. Weak test assertions (packages/backend/src/__tests__/climb-queries.test.ts): Several tests have assertions that always pass:

   • Line 73-78: The expect(climb).toBeDefined() inside the grade filter test doesn't actually validate the grade range
   • Line 264-265: expect(kilterResult === null || typeof kilterResult === 'object').toBe(true) - this will always be true since the result is either null or an object

3. Tests don't verify core functionality (packages/backend/src/__tests__/climb-queries.test.ts): The climb query tests rely on external database state (synced production-like data) rather than setting up known test fixtures. If the database is empty, tests like minAscents filter (line 81-95) will pass vacuously with 0 results.

[claude]

Claude Review

No significant issues found.

Minor observations:

• Duplicated schema definitions: setup.ts:80-232 duplicates table schemas that exist in packages/db/src/schema/. This could drift over time - consider importing from the schema package or using migrations for test DB setup to avoid maintaining parallel definitions.

[claude]

Claude Review

Issues Found:

1. Race condition in registerAndJoin helper (session-persistence.test.ts:158-165): The helper registers and joins in sequence but doesn't handle the case where joinSession throws before returning - the client remains registered but in an inconsistent state. This mirrors a potential real-world issue but may cause test pollution.

2. Missing client registration in concurrent join test (session-persistence.test.ts:304-307): The Promise.all calls registerAndJoin for clients 2-4 in parallel, but since registerClient is synchronous and joinSession is async, there's a subtle race where all three clients get registered before any joins complete. This works but doesn't accurately test the concurrent restoration scenario described in the test name.

3. Schema drift risk (setup.ts:22-228): The test setup manually defines table schemas via raw SQL strings rather than importing from the shared schema package. If the production schema changes, these test tables will silently diverge, causing tests to pass against an outdated schema.

4. Hardcoded test user ID (setup.ts:279-282): The test user 'user-123' is created with hardcoded values, but if a test modifies or deletes this user, subsequent tests in the same run could fail. Consider using unique user IDs per test or wrapping in a transaction.