keynmol
commented
2 years ago Glad I remembered this issue :) I can reproduce it without Scalacheck, in the following build: https://github.com/keynmol/jobby/actions/runs/3209965828/jobs/5247080202
What's fascinating is that in the same build I have tests that use exactly the same resource (that includes Skunk) (integrationTests) and they've never failed.
I attempted to give a more self-contained version of OP's snippet, with Scala CLI (run it with scala-cli test file.scala):
//> using lib "org.tpolecat::skunk-core:0.3.2"
//> using lib "com.disneystreaming::weaver-cats:0.8.0"
//> using testFramework "weaver.framework.CatsEffect"
//> using lib "com.disneystreaming::weaver-scalacheck:0.8.0"
//> using scala "2"
import cats.effect._
import skunk._
import skunk.implicits._
import natchez.Trace.Implicits.noop
import skunk.codec.text.text
import weaver._
import weaver.scalacheck._
import org.scalacheck.Gen
object SkunkWeaverSuite extends IOSuite with Checkers {
type Res = Resource[IO, Session[IO]]
// high count with low pool size (100, 1) triggers the issue consistently but will still trigger for
// low count / high pool size (1, 10), though not every time.
override def checkConfig: CheckConfig =
CheckConfig.default.copy(minimumSuccessful = 100)
override def sharedResource: Resource[IO, Res] = {
Session
.pooled[IO](
host = "localhost",
port = 5432,
user = "postgres",
database = "postgres",
password = Some("mysecretpassword"),
max = 50
)
}
test("skunk") { pool =>
forall(Gen.alphaNumStr) { _ =>
pool.use {
pg =>
pg.execute(sql"select version();".query(text)).map { v =>
expect(!v.isEmpty) // irrelevant
}
}
}
}
}But no matter how much I run it I can't seem to reproduce the issue.
So this leaves Weaver and Skunk, I will try to run skunk with debug logging to see if there's any hints.
This proved to be an issue when Skunk is used with Weaver and ScalaCheck. Not sure who's at fault here but hopefully this issue will serve as a good starting point.
Starting sbt console and running
testor~testwill produce this error on every single run, and querying forselect count(*) from pg_stat_activityonpsqlwill give an accumulated result += poolSize after each failed test run. Quitting and restarting sbt gets rid of the dangling connections.