Update client4:akka-http-backend, ... to 4.0.0-RC1

[softwaremill-ci]

About this PR

📦 Updates

• com.softwaremill.sttp.client4:akka-http-backend
• com.softwaremill.sttp.client4:core
• com.softwaremill.sttp.client4:fs2
• com.softwaremill.sttp.client4:ox
• com.softwaremill.sttp.client4:pekko-http-backend
• com.softwaremill.sttp.client4:upickle
• com.softwaremill.sttp.client4:zio

from 4.0.0-M19 to 4.0.0-RC1

📜 GitHub Release Notes - Version Diff

Usage

✅ Please merge!

I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.

If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.

Configure Scala Steward for your repository with a .scala-steward.conf file.

Have a fantastic day writing Scala!

🔍 Files still referring to the old version number

The following files still refer to the old version number (4.0.0-M19).
You might want to review and update them manually.

examples/src/main/scala/examples/ChatProxy.scala

⚙ Adjust future updates

Add this to your .scala-steward.conf file to ignore future updates of this dependency:

updates.ignore = [ { groupId = "com.softwaremill.sttp.client4" } ]

Or, add this to slow down future updates of this dependency:

dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.softwaremill.sttp.client4" }
}]

^{labels: library-update, early-semver-pre-release, semver-spec-pre-release, old-version-remains, commit-count:1}

[adamw]

@zygiert1990 shouldn't we throw DeserializationException here or the DeserializationOpenAIException wrapper?

[zygiert1990]

If I understand correctly how does it work I think not. In SttpUpickleApiExtension we have method deserializeJsonSnake, which actually does the deserialization. Inside this method there is try-catch block and it works in that way that it catches all exceptions and wraps them in DeserializationOpenAIException. Having this in mind I changed exception type in all implicit readers, as eventually they will be wrapped into another exception.

[adamw]

Ah, so it would be wrapped twice in effect?

By the way, do we still need DeserializationOpenAIException? Can't we just use DeserializationException?

[zygiert1990]

Yes indeed.

We could remove DeserializationOpenAIException, but we have such or similar signature in some methods Request[Either[OpenAIException, AudioResponse]]. If we remove this error we will have to adapt existing code (as we won't be able to use OpenAIException, as a base type here), which of course shouldn't be a problem, but the question is: does it bring to us any value? Doing so, we will break existing error hierarchy, as there are few others custom exceptions in this project, e.g. RateLimitException, which are also a subtypes of OpenAIException.

[adamw]

Ok, sounds reasonable, so we leave things as-is :)