-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CatsResourceIO in scalatest doesn't release the resource #300
Comments
I am also running into this problem. (here was some thought which does not make sense any longer since I read the scalatest issues you linked. But I am unable to delete this comment) |
The following workaround solves the problem for me (jvm): class TestExample extends FixtureAsyncFreeSpec with AsyncIOSpec with CatsResourceIO[Int] {
override val executionContext: ExecutionContext = ExecutionContext.global
// ...
} |
I think that changing only the execution context to the one which is backed by multiple threads can result in some concurrency issues as described in the first part. |
The only workaround that is actually working for me is using the global EC. Otherwise the resource defined here will never be deallocated/released: class RpcLocationServiceSpec
extends FixtureAsyncWordSpec
with AsyncIOSpec
with Matchers
with OptionValues
with AsyncMockFactory
with CatsResourceIO[IO[OutcomeIO[Nothing]]] {
abstract class MockUnLocationService(
unLocationRepo: UnLocationRepositoryAlgebra[IO],
logger: SelfAwareStructuredLogger[IO]
) extends UnLocationService[IO](unLocationRepo, logger)
implicit val unsafeLogger: SelfAwareStructuredLogger[IO] = Slf4jLogger.getLogger[IO]
private val testRpcPort: Int = 9095
private val mockLocationService = mock[MockUnLocationService]
private val rpcConfig = RpcConfig("127.0.0.1", testRpcPort)
// THE ONLY WORKAROUND THAT WORKS:
override val executionContext: ExecutionContext = ExecutionContext.global
override val resource: Resource[IO, IO[OutcomeIO[Nothing]]] =
RpcLocationService
.service[IO](mockLocationService, unsafeLogger)
.flatMap(RpcServerManager.startServer[IO](_, rpcConfig, unsafeLogger).useForever.background) |
We are also experiencing this problem with the simple reproducible code: import cats.effect.{IO, Resource}
import cats.effect.testing.scalatest.{AsyncIOSpec, CatsResourceIO}
import org.scalatest.wordspec.FixtureAsyncWordSpec
class TestMeSpec extends FixtureAsyncWordSpec with AsyncIOSpec with CatsResourceIO[Int] {
override val resource: Resource[IO, Int] = Resource.make(IO.pure(1).flatTap(id => IO.println(s"Acquired Resource: $id")))(id => IO.println(s"Released Resource: $id"))
"cats resource specifications" should {
"should acquire and release the resource" in { id =>
IO.print(s"I have the resource: $id")
}
}
} This only prints:
Whereas we expect it to instead print:
|
@djspiewak @sh0hei do you know who could look into this issue? It's been reported more than 1 year ago 🙏 |
I took a glance at CatsResource and it seems fine - I think the problem here is the ExecutionContext that the futures are running on being terminated before the shutdown step can complete. I'm not 100% certain though |
I believe this is happening due to an intentional design choice with ScalaTest's For async test suites this is performed as part of the deferred outcome / status that occurs when the test is run; However the Since the Using a different EC works because task execution is no longer dependant on being triggered during the test. Would there be any issues using a dedicated EC for the resources while still having IO in test delegated to the serial execution context? |
Info:
Given following example:
I would expect scalatest to release the fixture resource. Instead the resource is not being released.
I think that there are two problems with the current solution.
First, we schedule the shutdown action here: https://github.com/typelevel/cats-effect-testing/blob/series/1.x/scalatest/shared/src/main/scala/cats/effect/testing/scalatest/CatsResource.scala#L76 which is asynchronous and then we immediately clear the
shutdown
variable. This clear action has a potential to be executed before the scheduled future is run resulting in the release code not being evaluated.However, only rewriting that to something like:
Doesn't fix the problem.
The second part is somehow related to the execution context used by scalatest.
I didn't dig deep enough into the scalatest codebase to prove that but it seems to me that the execution context gets closed(?) as soon as the test suite completes.
Changing the EC used to evaluate future actions together with previous solution fixes the problem.
I am not saying that this is the correct solution, I am only including that to give more information about the underlying issue.
While trying to understand that issue I also came across these two issues which I think might be relevant:
beforeAllAsync
andafterAllAsync
for nowbefore
andafter
methods as defaultExecutionContext
is single threadedThe text was updated successfully, but these errors were encountered: