Group Scheduler Add/Remove Person Causes Rock Restart #6098
Labels
Status: Confirmed
It's clear what the subject of the issue is about, and what the resolution should be.
Type: Bug
Confirmed bugs or reports that are very likely to be bugs.
Comments
sparkdevnetwork-service
added
Status: Confirmed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
There is a configuration you can have that makes it so any time a person is added or removed to group scheduler (and the cache updates) a stack overflow occurs and causes that instance of Rock to restart without logging an error.
I can consistently create the error with the following configuration:
You need to have a minimum of 3 Group Types that are all allowed to have child groups of all three of the types. Then if you create a group tree structure of Parent-Child-Grandchild where each group is one of the three types. Now in the grandchild group if you use the scheduler whenever the cache is updated (you add or remove someone) you get an error on this line
My Group Types all look like this (I enabled scheduling on all three as well):
Group Tree Structure, the names match the Group types
In my experience with it, both the Group Type Cache and Defined Value Cache (if you set a Group Type Purpose) will throw the exception and crash the app. I'm guessing it is happening when the Group Type Cache is looking for valid parent group types and since everything is a possible parent of everything in this configuration there is no exit route for infinite recursion. Since you can't catch a stack overflow error and can't step out of it to see what called the
GetOrAddExistingmethod I can't give you an exact line or method that is causing the error.I did try with only two group types and two groups in the hierarchy and didn't get the error so there might be some checking for that parent-child relationship already (or I didn't do the configuration right when I tested that). But consistently when I have three group types and groups set up this way I can make the error happen. I have tried it on two different clean dbs with only code from a core branch (hotfix-1.16.7).
Group Scheduler is the route we found this in and seemed like the easiest way to report it for reproduction but the underlying problem is not actually in the code for the group scheduler. The issue likely with the Group Type cache not handling the possibility of infinite recursion when getting parent group types. Please feel free to edit/rename this so it makes more sense for you all.
Visual Studio Info:
In my example here the key is 38 which is the Id of Group Type One in my example.
The item factory is the GroupTypeCache.
They key factory is null.
Call Stack:
Actual Behavior
When you have a 3-deep hierarchy of groups and group types that are all allowed to have child groups of any of the three types. When trying to schedule people in the grand child group you get a Stack Overflow error when the GroupType cache is updating.
Expected Behavior
Any configuration of groups and group types in any hierarchy should work properly without causing rock to restart.
Steps to Reproduce
Create three group types with scheduling enabled. (I also enabled location schedules)
Make all three available as child group types for all three group types.
Create a group of the first group type.
Create a child group of that group that is the second group type.
Create a child of the previous child group (so grandchild to first group) that is the third group type.
Set up a meeting location for a schedule for the third (grandchild) group.
Add at least two people to this group.
Go to group scheduler and schedule someone or remove someone from the schedule.
If running locally you will get the stack overflow error and Visual Studio will break. If running on a system you should be able to see evidence of Rock restarting in the Application logs.
Issue Confirmation
Rock Version
16.7
Client Culture Setting
en-US
The text was updated successfully, but these errors were encountered: