Skip to content
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

Use UUIDGen instead of randomUUID() #678

Merged
merged 5 commits into from
Sep 15, 2022

Conversation

armanbilge
Copy link
Member

Fixes #677.

Comment on lines -56 to -60
.jsSettings(
// https://www.scala-js.org/news/2022/04/04/announcing-scalajs-1.10.0#fixes-with-compatibility-concerns
libraryDependencies += ("org.scala-js" %%% "scalajs-java-securerandom" % "1.0.0")
.cross(CrossVersion.for3Use2_13)
)
Copy link
Member Author

@armanbilge armanbilge Aug 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although in theory this dependency is secure, in practice it is not safe to rely on. See discussion in:

@@ -52,12 +53,26 @@ object PagingSelfAwareStructuredLogger {
* @return
* SelfAwareStructuredLogger with pagination.
*/
def withPaging[F[_]: Monad](pageSizeK: Int = 64, maxPageNeeded: Int = 999)(
def withPaging2[F[_]: Monad: UUIDGen](pageSizeK: Int = 64, maxPageNeeded: Int = 999)(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I wasn't feeling creative with naming at this moment 😅 I will happily change this to any suggestion, thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should name it paged? 🤔 and just keep that as the future API

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me! :)

new PagingSelfAwareStructuredLogger[F](
pageSizeK,
maxPageNeeded,
Monad[F].unit.map(_ => UUID.randomUUID())
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Terrible, right! But this just more clearly exposes the bad behavior that already existed here. There is no safe way to generate random UUIDs with only a Monad.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely! I'm just sorry I didn't catch it before

@lorandszakacs
Copy link
Member

LGTM! I'm fine with merging this. Leaving it open for other maintainers to weigh in.

@@ -46,18 +46,14 @@ lazy val core = crossProject(JSPlatform, JVMPlatform)
.settings(
name := "log4cats-core",
libraryDependencies ++= Seq(
"org.typelevel" %%% "cats-core" % catsV
"org.typelevel" %%% "cats-core" % catsV,
"org.typelevel" %%% "cats-effect-std" % catsEffectV
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to keep the initial goal of having the core module CE-less, can we introduce an internal interface for UUIDGen and its implementation within the slf4j module?

Copy link
Member

@lorandszakacs lorandszakacs Aug 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we instead create a new module that is explicitely dependent on CE? And move the correct version of this there?

I feel like re-defining a UUIDGen equivalent leads to a lot of confusion and bad UX. Instead, having a log4cats-core package that is honest about its limitations, and an extension logs4cats-ce (naming is hard) that overcomes aforementioned limitations might be better.

Although not entirely sure how to pull this off in a bincompat and user friendly way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, adding a "log4cats-effect" would be better for UX, but still not great for UX+bincompat.

Just so that we are clear: what are the arguments against just have a CE dependency in the core module?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what are the arguments against just have a CE dependency in the core module?

Very good question! I personally don't know since I probably missed those discussions during my absence. 🙈 Personally I think it's ok to have CE in core

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can only guess, but perhaps the reason is to apply the Rule of Least Power. But once again, I'm not sure if this is a thing still.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say it is a thing still :) The problem is the repo is currently applying the principle of too-little-power. This is a course-correction.

@armanbilge armanbilge mentioned this pull request Sep 9, 2022
@armanbilge
Copy link
Member Author

@danicheg so wdyt, can we move forward with adding CE to core?

If not, my best suggestion is to:

  1. Create a "log4cats-effect" module.
  2. Completely deprecate log4cats.PagingSelfAwareStructuredLogger as blocking and unfixable.
  3. Re-introduce it as log4cats.effect.PagingSelfAwareStructuredLogger or similar.

@danicheg
Copy link
Member

danicheg commented Sep 10, 2022

To sum up my thoughts:
I haven't a strict 'no' about having CE in the core module.
I was wondering – is it possible to preserve the initial goal of not having CE in the core module? Perhaps the only reason why this could be still a thing – is the principle of least power. That said if we will benefit from adding this dependency, then probably, we are good.
It'd be extremely helpful if the initial architects of log4cats would have a glance at this one. But based on common sense, I don't see much of the evil in adding CE to the core module.

@armanbilge
Copy link
Member Author

armanbilge commented Sep 10, 2022

I spoke with @ChristopherDavenport on Discord. Here's a quick summary:

Regarding CE in core:

Having cats-effect to in core I don't mind though. The idea was a bunch of abstractions and helpers there, with the effects of them in the helper modules. But... If we need the std to have cats-effect for those helpers. I'm fine with that.
Basically, core is like http4s core. (I reuse concepts)

Regarding UUIDs:

It's to identify all the split logs as a single log action.
So it's really just a string.
So I'm not seeing why it wouldn't be F[String] and let people define their own way, one of which could be via UUID and UuidGen


So it boils down to a question of UX:

  1. We can keep core on Cats only, and force users to bring their own F[String] since we cannot provide a default. This makes it harder for users to fix the deprecation.
  2. We can move ahead with this PR, which adds Cats Effect, and provides a default F[String] via UUIDGen[F]. Then in a follow-up we can make this customizable (or I can do it in this PR if it's easy).

Thoughts?

@danicheg thanks again for raising this issue, it's opened some good questions.

@danicheg
Copy link
Member

It comes that all of us don't mind adding the CE std module to the log4cats core. So let's move onward with this. 👍 from me to that.

@ChristopherDavenport ChristopherDavenport merged commit eb768c0 into typelevel:main Sep 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

randomUUID is blocking
4 participants