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

Implement workaround for initialization order errors in JVM lambdas #448

Merged
merged 3 commits into from
Jan 17, 2024

Conversation

armanbilge
Copy link
Member

Fixes a regression reported on Discord.

Previously, IOLambda was not sensitive to whether initializing the handler involved vals. This is because the definition of handler was used lazily on the first invocation of the lambda, not during its construction.

However, after the changes in #446, we now use the definition of handler eagerly during construction. A val in a superclass (i.e. IOLambda) is always initialized before vals in the subclass (i.e. user-defined FooLambda). This means that all vals in the subclass are uninitialized (i.e. null) when we initialize val handle in IOLambda.

The proper remedy for this situation is that users should always use def instead of val in their IOLambdas. However, because this is a highly surprising regression wrt the previous behavior, we now make a best-effort to detect this situation, log an actionable warning, and fallback to the old semantic where we initialize during the first invocation of the lambda.

There was an error initializing `FooLambda` during startup.
Falling back to initialize-during-first-invocation strategy.
To fix, try replacing any `val`s in `FooLambda` with `def`s.

I've published this PR as 0.3-97de28d-SNAPSHOT.

Comment on lines 55 to 58
Async[Resource[IO, *]].defer(this.handler).memoize.map {
case Resource.Eval(ioa) => ioa
case _ => throw new AssertionError
}
Copy link
Member Author

Choose a reason for hiding this comment

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

There will be an official way to do this soon.

@armanbilge armanbilge merged commit fa51e2f into typelevel:main Jan 17, 2024
9 checks passed
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.

None yet

1 participant