Bump cats-effect_2.12 from 0.4 to 3.3.1

[dependabot]

Bumps cats-effect_2.12 from 0.4 to 3.3.1.

Release notes

Sourced from cats-effect_2.12's releases.

v3.3.1

This is the sixteenth major release in the Cats Effect 3.x lineage. It is fully binary compatible with every 3.x release, and fully source-compatible with every 3.3.x release. Note that source compatibility has been broken with 3.2.x in some minor areas (detailed below). Scalafixes are available and should be automatically applied by Scala Steward if relevant.

This release contains bug fixes and performance enhancements to tracing and some other areas. Both enhanced exceptions and fiber dumps should now behave better on the latest versions of the JVM (which use a different top-level package identifier). Tracing on Scala.js can now be fully disabled if its overhead is too high, whereas previously some bookkeeping was retained even when tracing was configured to off.

Most significantly, Resource.uncancelable previously contained a significant bug in which error states were rewritten within the block. This ultimately stemmed from a limitation in the original Resource API with respect to full representation of outcomes, and it indirectly impacted all use of Async[Resource]. Thanks to the efforts of @​TimWSpence, these bugs have now been completely squashed with the addition of a new Resource interpreter: allocatedCase (originally proposed by @​kubukoz). In the interest of maintaining forward-compatibility, this function is currently marked as package-private, but will be marked as public in Cats Effect 3.4.0.

User-Facing Pull Requests

• #2617 – Add Resource#allocatedCase (@​TimWSpence)
• #2665 – Fixes cancelling CompletableFuture on fiber cancellation (@​LightSystem)
• #2662 – micro-optimization: use Map.empty instead of Map.apply (@​yanns)
• #2642 – Only use FiberAwareExecutionContext if tracing is enabled (@​armanbilge)
• #2623 – Add jdk. to trace filter (@​armanbilge)
• #2609 – Fix trace filtering (@​alexandrustana)
• #2607 – Duplicated fibers in fiber dump (@​TimWSpence)
• #2600 – Handle interruption gracefully and halt the runtime on fatal errors (@​vasilmkd)
• #2654, #2635, #2647, #2629, #2591 – Documentation fixes and improvements (@​danicheg, @​zarthross, @​danicheg, @​xuwei-k, @​djspiewak)

Heartfelt thanks; you are all amazing!

v3.3.0

This is the fifteenth major release in the Cats Effect 3.x lineage. It is fully binary compatible with every 3.x release, and fully source-compatible with every 3.3.x release. Note that source compatibility has been broken with 3.2.x in some minor areas (detailed below). Scalafixes are available and should be automatically applied by Scala Steward if relevant.

The theme of this release has been improving observability, testability, and debuggability of all applications using Cats Effect 3. This has resulted in a massive set of new functionality, tweaks, and improvements which make 3.3.0 the most significant Cats Effect release ever apart from 3.0.0 itself. The developer experience has been significantly improved, particularly in tricky areas such as diagnosing deadlocks and deterministically testing functionality involving timers and clocks. Additionally, new functionality has been brought to Scala.js, including full support for tracing!

Finally, we took the opportunity to continue to build on IO's best-in-class performance with significant improvements to the fiber runtime (including dynamic workload fairness self-tuning) and continued dramatic slimming of the fiber memory footprint. Embarrassingly, we even discovered that the build was using an unnecessary Scala compiler flag which inhibited performance in some scenarios (particularly involving large numbers of fibers) by up to 15%! All of these improvements should add up into a very noticeable leap forward for application metrics in nearly all real-world scenarios.

Notable Changes

Thread Fiber Dumps

One of the most annoying and difficult problems to resolve in any asynchronous application is the asynchronous deadlock. This scenario happens when you have a classic deadlock of some variety, where one fiber is waiting for a second fiber which is in turn waiting for the first (in the simplest case). Due to the asynchronous nature of the runtime, whenever a fiber blocks, all references to it are removed from the internal runtime, meaning that a deadlock generally leaves absolutely no residue whatsoever, and the only recourse as a developer is to just start sprinkling IO.println expressions around the code to see if you can figure out where it's getting stuck.

This is very much in contrast to a conventional deadlock in a synchronous runtime, where we have JVM-level tools such as thread dumps to suss out where things are stuck. In particular, thread dumps are a commonly-applied low level tool offered by the JVM which can serve to inform users of what threads are active at that point in time and what each of their call stacks are. This tool is generally quite useful, but it becomes even more useful when the threads are deadlocked: the call stacks show exactly where each thread is blocked, making it relatively simple to reconstruct what they are blocked on and thus how to untie the knot.

Fiber dumps are a similar construct for Cats Effect applications. Even better, you don't need to change anything in order to take advantage of this functionality. As a simple example, here is an application which trivially deadlocks:

import cats.effect.{IO, IOApp}
object Deadlock extends IOApp.Simple {
val run =
for {
latch <- IO.deferred[Unit]
  body = latch.get
  fiber &lt;- body.start
  _ &lt;- fiber.join

</tr></table>

... (truncated)

Commits

• 4c281f0 Merge pull request #2669 from djspiewak/bug/flaky-test
• ab402e1 Reduced timing dependence of spec
• 04bf0d2 Merge pull request #2617 from TimWSpence/issue-2472
• e803dc4 Hide allocatedCase for now
• 06337f0 Merge pull request #2665 from LightSystem/cancel-cf
• 0c05412 Fixes cancelling CompletableFuture on fiber cancellation instead of the stage...
• 6b3b6de Merge pull request #2662 from yanns/micro_optimize_IOFiber_Map
• 7ba9eb0 micro-optimization: use Map.empty instead of Map.apply
• a410503 Merge pull request #2654 from danicheg/delay-scaladoc
• aa0b084 More concise spelling
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #194.