Skip to content

Conversation

jorenretel
Copy link

@jorenretel jorenretel commented Aug 29, 2025

Hi Jonvet,

thanks for solving this problem! I ran into it as well and found your PR (tadata-org#156). When I used your proposed fix though I found that there is one specific case where the current version of the code makes a mistake. It happens when a model has two properties on the same level that are of the self-referencing type. When this happens the second (and following...) properties are treated differently than the first one although they are at the same level.

Adding a copy to the seen set before handing it to new passes of resolve_schema_references makes sure that this does not happen as the first instance is not updating the parent set.

An example where this would happen:


class Player(BaseModel):
    name: str
    number_of_games: int
    teacher: Optional[Player] = None  # self-referencing

class Game(BaseModel):
    playerA: Player
    playerB: Player


In this case playerB will be represented by the $ref while playerA is allowed one level of recursion.

… updating the same set and influencing how properties on the same level are treated
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.

1 participant