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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jun 10, 2026 8:03pm

PR Summary

Medium Risk
Touches billing ledger writes and lock semantics on a hot internal path; behavior should be equivalent when locks clear quickly, but lock timeout can surface new retryable failures under contention.

Overview
Fixes pool starvation on cumulative usage flushes (recordCumulativeUsage, used by /api/billing/update-cost) by moving resolveBillingContext outside the advisory-lock transaction and passing the pre-resolved entity/period into the first-flush recordUsage insert, so subscription lookups no longer run on the global pool while a connection holds the per-event-key lock.

Inside the transaction, sets a 3s lock_timeout before acquiring the lock and switches the lock key to pg_advisory_xact_lock(hashtextextended(...)) so stuck waits fail fast (retryable) instead of pinning pooled connections. Vitest coverage asserts call order, stamped billing fields on insert, and the lock/timeout SQL.

^{Reviewed by Cursor Bugbot for commit 7084891. Configure here.}

Greptile Summary

This PR fixes a pool-starvation deadlock in /api/billing/update-cost by moving resolveBillingContext outside the transaction so subscription lookups no longer compete for pooled connections while the advisory lock is held, and bounds the lock wait with a 3-second lock_timeout using a 64-bit hashtextextended key.

• usage-log.ts: billing context is now resolved before db.transaction(), the advisory lock switches from 32-bit hashtext to 64-bit hashtextextended, and set_config('lock_timeout', '3000ms', true) is added to fail stuck flushes fast (SQLSTATE 55P03) within the Go retry budget.
• usage-log.test.ts: three new tests verify pre-transaction ordering of the subscription lookup, that the pre-resolved context is stamped on the first-flush insert, and that the lock timeout and 64-bit hash SQL are executed inside the transaction.

Confidence Score: 3/5

The deadlock fix is sound, but every top-up flush (the majority of calls after the first) now performs a subscription lookup that is discarded unused, adding extra DB load on a high-traffic billing endpoint.

Moving billing context resolution out of the transaction correctly eliminates the pool-starvation deadlock and the lock changes are technically correct. However, the unconditional pre-transaction resolveBillingContext call means every UPDATE-path flush (all subsequent flushes for a multi-leg request) incurs a getHighestPrioritySubscription query that wasn't there before and whose result is never used. On a high-frequency billing path this adds measurable extra load per request. The test helper also accesses a Drizzle-internal property, making the new lock verification tests fragile to Drizzle upgrades.

apps/sim/lib/billing/core/usage-log.ts — the unconditional billing context resolution before the transaction.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Caller
    participant recordCumulativeUsage
    participant resolveBillingContext
    participant DB_Pool
    participant Transaction

    Caller->>recordCumulativeUsage: "{userId, eventKey, cost, ...}"
    note over recordCumulativeUsage: BEFORE (old): billingContext resolved inside tx
    note over recordCumulativeUsage: AFTER (new): billingContext resolved BEFORE tx
    recordCumulativeUsage->>resolveBillingContext: resolveBillingContext(userId)
    resolveBillingContext->>DB_Pool: getHighestPrioritySubscription(userId)
    DB_Pool-->>resolveBillingContext: subscription
    resolveBillingContext-->>recordCumulativeUsage: "{billingEntity, billingPeriod}"

    recordCumulativeUsage->>DB_Pool: db.transaction()
    DB_Pool->>Transaction: acquire connection
    Transaction->>Transaction: "SET lock_timeout = '3000ms' (tx-local)"
    Transaction->>Transaction: pg_advisory_xact_lock(hashtextextended(eventKey, 0))
    Transaction->>Transaction: SELECT existing row
    alt existing row found (UPDATE path)
        Transaction->>Transaction: UPDATE cost to newTotal
        note over Transaction: billingContext resolved above — unused here
    else first flush (INSERT path)
        Transaction->>Transaction: INSERT with pre-resolved billingEntity/billingPeriod
    end
    Transaction-->>DB_Pool: release connection + advisory lock
    DB_Pool-->>recordCumulativeUsage: result
    recordCumulativeUsage-->>Caller: "{billed, delta, total}"

_{Reviews (1): Last reviewed commit: "fix(billing): prevent deadlock with time..." | Re-trigger Greptile}