feat: transactions and rls rules

[geclos]

Summary

Implements Row-Level Security (RLS) policies and SQL transaction management across the entire stack, from database schema to API boundaries.

SQL Transactions

All sql operations are handled by the SqlClient service. SqlClient abstracts the underlying sql platform as well as the RLS enforcement.

Platforms provide SqlService implementations and app boundaries inject them in the use cases that need them.

1. Domain Layer (@domain/shared): SqlClient interface—platform-agnostic contract
2. Platform Layer (@platform/db-postgres): SqlClientLive implementation with RLS
3. App Layer (apps/*): Provides SqlClientLive layer with organization context

Usage in Code

Repositories use sqlClient.query() for single operations:

findById: (id) =>
  sqlClient
    .query((db) => db.select().from(projects).where(eq(projects.id, id)))
    .pipe(Effect.flatMap(...))

.query checks if in transaction, if not it opens one and enforces RLS, if yes it's a pass-through proxy.

Use cases wrap multi-step operations in sqlClient.transaction():

export const completeAuthIntentUseCase = (input) =>
  Effect.gen(function* () {
    const sqlClient = yield* SqlClient
    yield* sqlClient.transaction(handleIntentByType(intent, input.session))
  })

.transaction checks if in transaction, if not it opens one with RLS enforced and updates the context so that any underlying effects pull from this transaction rather than the global sql client. If in transaction, it's a pass-through proxy.

Boundary routes provide the SqlClient layer with organization context:

// apps/api
const project = await Effect.runPromise(
  createProjectUseCase(input).pipe(
    Effect.provide(ProjectRepositoryLive),
    Effect.provide(SqlClientLive(c.var.postgresClient, c.var.organization.id)),
  )
)

// apps/web
const project = await Effect.runPromise(
  createProjectUseCase({...}).pipe(
    Effect.provide(ProjectRepositoryLive),
    Effect.provide(SqlClientLive(client, organizationId)),
  )
)

Boundaries provide the sql client implementation with proper context. Most of the times this means a postgres client + a tenant id (the ord id). For non-rls ops simply pass the admin postgres client. If you pass the regular postgres client without org id, rls will fail on any rls-protected underlying operation.

Key Behaviors

• Every transaction automatically sets app.current_organization_id session variable
• RLS policies filter all queries at the database level
• No nested transactions (pass-through proxy)
• Domain errors propagate through Effect error channel
• Any failure triggers automatic rollback

Files Changed

• packages/domain/shared/src/sql-client.ts — Domain SqlClient interface
• packages/platform/db-postgres/src/sql-client.ts — RLS-enabled transaction implementation
• packages/platform/db-postgres/src/schemaHelpers.ts — RLS policy helper
• packages/platform/db-postgres/drizzle/* — Migration files for RLS function
• apps/*/routes/*.ts — Updated routes to provide SqlClient layer
• apps/web/src/domains/*/*.functions.ts — Server functions with RLS context
• packages/**/repositories/*.ts — Repositories using sqlClient.query()
• packages/**/use-cases/*.ts — Use cases using sqlClient.transaction()

[geclos]

@cursoragent fix my comments

[cursor]

All changes are pushed. Here's a summary of what was fixed for each PR comment:

• apps/api/src/middleware/auth.ts: Restored validateApiKey to return an Effect instead of a Promise, eliminating the unnecessary Effect-to-Promise-to-Effect round-trip. authenticateWithApiKey now yields directly from it.

• apps/api/src/routes/api-keys.test.ts (insert): Replaced raw SQL INSERT with Drizzle ORM database.db.insert(postgresSchema.apiKeys).values({...}).

• apps/api/src/routes/api-keys.test.ts (select): Replaced raw SQL SELECT with Drizzle ORM database.db.select(...).from(...).where(...) using eq from drizzle-orm.

• apps/api/src/test-utils/create-test-app.ts: Replaced all four raw SQL inserts (user, organization, member, api_keys) in createTenantSetup with Drizzle ORM inserts using postgresSchema.

• apps/api/src/test-utils/in-memory-postgres.ts: Removed the unused withRls method and its OrganizationId import.

  

[geclos]

@cursoragent review

[cursor]

Now I have a complete picture. Let me compile the review.

Here is my review of the PR:

---

Overall

Strong architectural direction. The SqlClient abstraction cleanly separates transaction management and RLS enforcement from domain logic, and the ports-and-adapters wiring is consistent. The bulk of the PR is solid. Below are the findings worth addressing, ordered by severity.

---

Critical

1. subscription-repository.ts:97-100 -- exists() always returns true

sqlClient.query(db => db.select(...).limit(1)) returns an array. The .pipe(Effect.map(result => result !== undefined)) checks whether the array itself is undefined -- it never is, so this always returns true.

// Current (broken)
.pipe(Effect.map((result) => result !== undefined))

// Fix
.pipe(Effect.map((results) => results.length > 0))

2. auth.functions.ts:159-162 -- exchangeCliSession creates API key in wrong org

SqlClientLive(adminClient) defaults organizationId to "system". The generateApiKeyUseCase reads organizationId from SqlClient, so the API key is persisted with organization_id = "system" instead of the user's active organization. The Redis entry stores the correct activeOrganizationId, creating a mismatch.

// Current
Effect.provide(SqlClientLive(adminClient))

// Fix -- pass the user's org
Effect.provide(SqlClientLive(adminClient, OrganizationId(activeOrganizationId)))

3. complete-auth-intent.test.ts:314-335 -- Test swallows all errors

The "skips organization creation for signup when existingAccountAtRequest is true" test catches all exceptions and does not assert the expected outcome. Any failure (including mock misconfiguration) is silently swallowed. It should assert on observable state, e.g. that the auth intent was consumed and no organization was created.

4. projects.ts:280-293 / softDelete -- Cross-tenant DELETE returns 204 instead of 404

softDelete runs UPDATE ... SET deleted_at = ... WHERE id = $1. With RLS, the row is invisible to a different tenant, so 0 rows are updated and the effect succeeds silently. The route unconditionally returns 204. This is misleading -- the API spec declares a 404 response but it is never triggered for cross-tenant deletes.

Fix options: have softDelete check affected rows and fail with NotFoundError when 0, or call findById before soft-deleting.

---

Warnings

5. Multi-step use cases missing transaction()

Several use cases perform check-then-act patterns (read, validate, write) without wrapping in sqlClient.transaction(). Each sqlClient.query() opens its own transaction, so there is no atomicity between steps:

• create-project.ts: existsByName + existsBySlug + save -- race allows duplicate slug
• update-project.ts: findById + existsByName + save -- TOCTOU race on name uniqueness
• revoke-api-key.ts: findById + save -- read and write not atomic
• change-plan.ts: findActive + findBySubscription + revokeBySubscription + saveMany + save -- partial failure leaves inconsistent state

Recommendation: wrap multi-step DB flows in sqlClient.transaction().

6. members.functions.ts:42 -- findPendingInvitesByOrganizationId is not org-scoped

The auth_intent table has no RLS and the method does not filter by organization. listMembers can return invites belonging to other organizations. Either add org filtering in the repository query, or filter at the handler level.

7. projects.test.ts:22-26 -- Raw SQL still used for project seed data

createProjectRecord uses database.client.query with raw SQL. The review feedback on api-keys.test.ts was applied, but the same pattern remains in projects.test.ts. Should use Drizzle database.db.insert(postgresSchema.projects).values(...) for consistency, and the verification SELECT at line 97 should also use Drizzle.

8. sql-client.ts:29 -- Default OrganizationId("system") can hide mistakes

When no org ID is passed, SqlClientLive silently defaults to "system". If a developer forgets to pass the org, queries run against "system" rather than failing fast. Consider making organizationId required for tenant-scoped use, or using a clearly distinct sentinel that causes RLS to deny access.

---

Nits

9. auth-intent-repository.ts -- Redundant mapError(toRepositoryError(...))

sqlClient.query() already wraps errors in RepositoryError. The extra .pipe(Effect.mapError(...)) double-wraps without benefit. Can be removed for cleaner error chains.

10. membership-repository.ts:90 -- Unsafe as Effect.Effect<...> cast

The type assertion hides the real error type. Prefer letting TypeScript infer the types or narrowing explicitly.

11. Pattern inconsistency: Effect.provide vs Layer.merge + Layer.provide

API routes use Effect.provide(RepoLive).pipe(Effect.provide(SqlClientLive(...))), while web datasets.functions.ts uses Layer.merge(...).pipe(Layer.provide(SqlClientLive(...))). Both work but diverge in style. Standardizing would improve readability.

12. in-memory-postgres.ts:51-59 -- createRlsMiddleware does not verify role exists

If latitude_app is missing (e.g. migration order change), SET ROLE fails but PGlite may not surface it clearly, causing tests to silently run as owner and bypass RLS.

---

Summary

Severity	Count	Key items
Critical	4	exists() bug, wrong org on CLI key, test swallowing errors, silent cross-tenant delete
Warning	4	Missing transactions, unscoped invites query, raw SQL in test, default org hiding bugs
Nit	4	Redundant error wrapping, unsafe cast, style inconsistency, role check

  

[geclos]

@cursoragent lockfile is stale. Pnpm install and commit the updated lock file

[cursor]

The lockfile is already in sync — pnpm install --frozen-lockfile succeeds. The CI failure was against an older commit (859f8b67) that predates the lockfile fix. The current HEAD (62319728d) already has the correct lockfile. CI should pass on the next run against the latest push.