codegen: handle recursive schema defns in scala 3 #4671
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hughsimpson
commented
Jun 25, 2025
|
|
||
| "schemas generated for recursive types are ok" in { |
There was a problem hiding this comment.
In a sense, this test is redundant, since the scripted tests will just timeout on the run stage without the fix. But tests are still nice, aren't they?
|
Test failure is unrelated ( |
|
Yeah that's a known limitation (https://tapir.softwaremill.com/en/latest/endpoint/schemas.html#derivation-for-recursive-types). Keeping compatibility between Scala 2 & Scala 3 isn't always that easy ;) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Supports deriving schemas for recursive schema definitions in scala 3.
Without this change, the code will hang eternally at runtime. This appears to be because, when declared as a
lazy val, the tapir schema for a recursive struct enters some infinite loop.defdeclarations have no such issues; howeverlazy valis, probably, preferable for most cases becase the schema only needs to be evaluated once, even if used in multiple locations - so there's a little extra complexity in the generation now, so that we only declare the schemas asdefs when they're recursive (or part of a mutually-recursive set of defns, which had the same issue).I guess it'd be nicer to fix the 'root issue' with lazy val schema declarations, but that's probably some magnolia issue that I have not the wit to fix, and this approach does well enough.