IA-5415: Fix org unit types infinite recursion - #3342
Merged
Merged
Conversation
Phil-V
marked this pull request as ready for review
September 23, 2026 09:07
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
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.
What problem is this PR solving?
The OrgUnitType api could throw RecursionError when
sub_unit_typesorallow_creating_sub_unit_typesreferences were forming a loop. This PR adds extra validation to prevent these cycles and makes the API more resilient against existing loops.Related JIRA tickets
IA-5415
Changes
allow_creating_sub_unit_typesto prevent loops.How to test
Field validation:
Api resilience against loops:
sub_unit_typesandallow_creating_sub_unit_typesattributes.GET /api/v2/orgunittypes/?fields=id,name,sub_unit_typesGET /api/v2/orgunittypes/?fields=id,name,allow_creating_sub_unit_typeGET /api/v2/orgunittypes/1/hierarchy/(with the pk of a type involved in the loop)Print screen / video
/
Notes
DynamicFieldsModelSerializerstill use thefieldsparam from the request to override the default fields, creating the potential for recursion. Judging from how the serializers were defined (with a list of fields that don't include the subtypes), this was likely not to be the intended response. As a workaround,ignore_dynamic_fieldswas added to suppress that behavior.Doc
/