-
Notifications
You must be signed in to change notification settings - Fork 154
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
Added support for disabling loading all site collection term groups #1069
base: dev
Are you sure you want to change the base?
Conversation
It is now possible to specify which term groups should be loaded when initializing the token parser. By default all groups including site collection specific ones are loaded. If disabled, only normal term groups will be loaded, which reduces the amount of data to retrieve from SharePoint.
A "LoadSiteCollectionTermGroups" property has been added to the "ApplyConfiguration" class. Additionally various usages of the "TokenParser" class have been updated to now also provide the template applying information.
"ObjectTermGroups" and "ObjectHierarchySequenceTermGroups" now also respect "LoadSiteCollectionTermGroups" when loading term groups.
It looks like that this is a general issue, which also affects the frontend. At least the management part of the term store ( {
"error": {
"code": "generalException",
"message": "The request uses too many resources."
}
} The management page previously never returned all site collection term groups. Only the one for the current site. Something definitely changed starting last monday. |
The previous change exclude site collection term groups from being loaded by the token parser and the object handler for term groups when specified. This introduced an issue where "termsetid" token, which reference a site-specific term set, could no longer be resolved because the group was excluded. To remedy this, the site collection term group now gets explicitly processed in both the token parser and the object handler. The token parser will add additional "termsetid" token if required and the object handler includes the term group again in the list groups to process. (cherry picked from commit 9993f2f)
The issue with the frontend seems to be fixed, but CSOM still returns all site collection term groups (you have access to?). This might not be an issue if a tenant with a large amount of sites only has "a hand full" of those with an own term group, but on tenants where a lot of the sites has an own one, this will causes timeouts. Regardless of that I just made another change, because we identified an issue which was not immediately apparent. Due to the previous changes when using To fix this, the token parser now explicitly adds the term sets of a site collection group with a |
This pull requests adds the support to disable the loading of all site collection-related term groups when initializing the
TokenParser
.Currently
TokenParser.AddTermStoreTokens
would load all available term groups from the term store when at least onetermsetid
token was found. Yesterday (2024-10-07) at 9:21 UTC we encountered the first instance of a timeout issue on one larger tenant, which was clearly caused by theAddTermStoreTokens
method ofTokenParser
due to the stack trace. The request was canceled after three minutes.After some manual tests we figured out that loading all available term groups with their term sets caused the issue. Removing the term sets from the loading process solved the problem, but would defeat the purpose of the whole operation. During those tests we also realized that loading the term groups without any conditions would return (on that tenant) over 29,000 entries. Most of them were site collection term groups. The same operation on another large tenant finished after a few seconds, but returned only around 28,800 entries. So we don't know if this is just an issue on that one specific tenant, or if 29,000 is somehow a magic barrier and the other tenant is just on the edge to experience the same issue.
This could also be caused by one or more site collection term groups, which contain a larger amount of term sets, but we have not checked this yet. It also does not make in most cases sense for PnP to load all term groups including the site collection ones, because most templates might contain a reference to the site collection term group of the site it gets applied to, but not references to those from other site collections. Excluding them also greatly reduces the amount of tokens the
TokenParser
has to handle.To remedy this issue we added the
LoadSiteCollectionTermGroups
property to theProvisioningTemplateApplyingInformation
andProvisioningTemplateCreationInformation
class. It istrue
by default to ensure the same behavior as before. Changing it tofalse
will change the query with which the term groups get loaded from a normalLoad
to aLoadQuery
, that excludes all groups which are related to a site collection (IsSiteCollectionGroup
property). Thesitecollectionterm
token are not affected by this change andAddTermStoreTokens
will still load information about the term group of the current site collection. Beside theTokenParser
classObjectTermGroups
andObjectHierarchySequenceTermGroups
have been changed too, because they also load all term groups and would cause the same issue.We tested the changes and deployed them already to our production environment using a reference to the project instead of using the NuGet package, because it was no longer possible to deploy any templates due to the timeout issue. We haven't seen any issues related to the changes yet. The hierarchy-related logic has also been changed, but because we don't use it it was not easily possible to test.