CI / Frozen lockfile install (pull_request) Successful in 49s
CI / Secrets not embedded (E00-S02-T08) (pull_request) Successful in 26s
CI / Database-postgres import isolation (E00-S03-T02) (pull_request) Successful in 26s
CI / Migration ledger (E00-S03-T03) (pull_request) Successful in 45s
CI / Migration advisory lock (E00-S03-T04) (pull_request) Successful in 50s
CI / Compose config (E00-S03-T01) (pull_request) Successful in 25s
Security-review finding F2: two concurrent acquire() calls on the same MigrationLock instance could each check out a connection; the second pg_advisory_lock would overwrite this.client, leaking the first locked connection until session end. acquire() now memoizes the in-flight acquire in acquireInFlight and returns it on re-entry, so exactly one connection is checked out and no locked connection leaks. The memo is cleared once the acquire settles. tryAcquire()/release() paths unchanged. Locked in by: - static criterion test: acquireInFlight field, re-entry guard returns the in-flight acquire, memo cleared on settle - mutation probe: removing the re-entry guard fails the criterion - real-stack probe: two concurrent acquire() calls on one instance leave pool.totalCount at 1 (exactly one connection), the lock granted once, nothing left after release; probe fails (hangs) on the pre-fix code - CI job comment updated to reflect the re-entrancy criterion