Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Integration sync lock: make DATABASE_URL work behind a transaction pooler

Open
  • Is something wrong?
#371 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
28/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
postgresql, typescript
Domain
backend, databases

Research direction

Start in app/src/db/postgres.ts with withPostgresAdvisoryLock and the existing tryWithPostgresAdvisoryLock, which already holds a transaction lock for the sweep. Then read integrations/sync/keyed-lock.ts to see how the sync calls the lock. Done when the sync lock uses pg_advisory_xact_lock on a dedicated client, tests T01 to T03 pass (including a transaction-mode pooler double), and the wording in docs/deployment-vercel.md and .env.example is updated.

Written by the indexing model from the issue text.

Description

area: ops type: feature

Part of #316 (found in the review of #333, PR #370).

Problem

withPostgresAdvisoryLock (app/src/db/postgres.ts) serializes the integration sync of one GitHub installation (integrations/sync/keyed-lock.ts; runs on installation webhooks and in the daily /api/internal/repository-sync) with a session-level advisory lock: pg_advisory_lock, then pg_advisory_unlock on the same session, on a pg.Client opened from DATABASE_URL.

Behind a transaction pooler (or statement mode) the lock and the unlock can land on different server connections. The serialization is lost, and a lock can stay held on a pooled backend, so later syncs of that installation wait forever.

The hosted deployment guide (docs/deployment-vercel.md) therefore says DATABASE_URL must be a direct or session-mode connection. A hosted deployment on a transaction pooler (the usual choice for serverless functions) is not possible until this is fixed.

Scope

  • Hold the sync lock as a transaction lock (pg_advisory_xact_lock) in a transaction that stays open on a dedicated client for the whole job, as tryWithPostgresAdvisoryLock already does for the sweep (#328), so it also works behind a transaction pooler and can never stay behind.
  • Keep the behavior for SQLite and for a direct connection.
  • Then relax the sentence in the guide and in .env.example.

Out of scope

Pool sizing, other poolers' features.

Test cases

ID kind level case expected
T01 regression integration two syncs of one installation at once the second waits, then runs; none runs concurrently
T02 regression integration the connection dies while the job runs the lock is released and the job is reported as failed, as today
T03 regression integration a pooler in transaction mode between app and database (a test double or a real pooler container) both syncs serialize and no lock stays held
Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
1h 18m
Merged PRs (30d)
284

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ExpidetGames/code-reviewer

All issues in ExpidetGames/code-reviewer

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.