Initialization bug with helpers over `test`

[BalmungSan]

I found a strange issue with weaver around initialization... or at least that is what I think. It is a bit involved but hopefully, I can provide enough info for someone to take a look.

// First, we need a base Suite with a bunch of helpers:
trait FooBaseSuite extends IOSuite:
  override final val maxParallelism: Int = 1
  override final type Res = FooRes
  override final val sharedResource: Resource[IO, Res] = ???

  // Define helper method to reduce boilerplate:
  protected def fooTest(name: String)(check: Foo => Expectations): Unit =
    test(name) { foo =>
      IO(check(foo))
    }

// Then we need an object that extends such base Suite:
object FooSpec extends FooBaseSuite:
  // And use the helper method:
  fooTest(name = "Testing foo") { foo =>
    expect(...)
  }

The tests will fail because Foo is already closed (or so I think).

There are a couple of ways to fix the issue:

1. Don't have a trait + object but just a single object
2. Remove the fooTest helper and replicate the boilerplate in each test
3. Make FooSpec a class which accepts an (unused) GlobalRead

Things that didn't work:

• Using abstract class rather than trait
• Moving fooTest from the trait (FooBaseSuite) to the object (FooSpec)

More info:

• Scala 3.3.1
• weaver: 0.8.3
• cats-effect: 3.5.1
• sbt: 1.9.6
• Java: GraalVM CE 17.0.8
• OS: Mac 14.0

[Baccata]

Hey @BalmungSan, thanks for reporting, but the information provided is not sufficient to reproduce (ie, I tried to replicate and couldn't), and insufficient to guess what's going on.

Any chance you could attempt to create a minimal reproduction ? (I appreciate it may not be easy).

Are you running the test from SBT in your terminal, or from your IDE ?

[BalmungSan]

Hi @Baccata thanks for looking into it.

Yeah, I know I should have come with a reproducer, but I have been a little bit busy. I will try to create one ASAP.

Meanwhile, I can provide with you a couple more details.

I am running the tests directly from sbt, using integrationTest/test (yes, they are in its own module). The resource I am running is a Docker container (using testcontainers-scala), which contains an HTTP app. And the reason why I think it is being closed is because the test fails with an "empty response" error.