Get-PNPSiteCollectionAppcatalogs slower in 1.11.0 and later

[Ambergahill]

Reporting an Issue or Missing Feature

I recently noticed that calling the Get-PNPSiteCollectionAppcatalogs command used to take a few seconds and now seems to run forever. I tracked it down to it working fine in 1.10.0. In 1.11.0, it errors out. This was the same time you introduced Get-PNPSiteCollectionAppcatalog (singular) and started throwing a warning to stop using Get-PNPSiteCollectionAppcatalogs. I am assuming it is related to this. In 1.12.0, the error with it crashing seems to be fixed, but now it does not run quickly anymore. The results are the same whether you use Get-PNPSiteCollectionAppcatalog or Get-PNPSiteCollectionAppcatalogs

Expected behavior

Get-PNPSiteCollectionAppcatalog should return all sites with an app catalog in a reasonable amount of time.

Actual behavior

Works fine in 1.10.0. Crashes in 1.11.0. Takes forever in 1.12.0 and later. See screenshot

Steps to reproduce behavior

Load PnP module 1.12.0 or later. Connect to tenant. Run Get-PNPSiteCollectionAppcatalog. Our tenant is very large with 108,457 sites and 4,554 sites have app catalog. Not sure if you will be able to repro this is a small environment.

What is the version of the Cmdlet module you are running?

Works fine in 1.10.0. Crashes in 1.11.0. Takes forever in 1.12.0 and later.

Which operating system/environment are you running PnP PowerShell on?

• Windows
• Linux
• MacOS
• Azure Cloud Shell
• Azure Functions
• Other : please specify

[KoenZomers]

Thanks for reporting this @Ambergahill . I did some digging into this scenario. I can trace the reason for what you are experiencing back to June 29, 2022, this commit specifically. We had an issue reported to us that this cmdlet would return the old URLs if the URL had been changed. To fix that, what we're doing now, is for every result, we are actively checking one by one if the URL that is passed back is still the actual one or if it has been renamed. This is what makes it slower now, especially if you have a bunch of these site collection app catalogs.

What I could do is add an optional new flag to the cmdlet to bypass this extra validation check which we've added last year. With that though, it would happen again that it returns URLs that have been renamed and no longer exist, but it would be back at the speeds you have experienced before. Would that help you out?

[Ambergahill]

Yes, that would be great. Thank you! From: Koen Zomers ***@***.***> Sent: Friday, April 14, 2023 9:36 AM To: pnp/powershell ***@***.***> Cc: Ambergahill ***@***.***>; Mention ***@***.***> Subject: Re: [pnp/powershell] Get-PNPSiteCollectionAppcatalogs Broken in 1.11.0 and later (Issue #2986) Thanks for reporting this @Ambergahill<https://github.com/Ambergahill> . I did some digging into this scenario. I can trace the reason for what you are experiencing back to June 29, 2022, this commit<9e6f991#diff-8b81d2f40d6ca9db2404bf4a869eee1e08fd4aa452dfb6f13506937fe930b9fb> specifically. We had an issue<#2041> reported to us that this cmdlet would return the old URLs if the URL had been changed. To fix that, what we're doing now, is for every result, we are actively checking one by one if the URL that is passed back is still the actual one or if it has been renamed. This is what makes it slower now, especially if you have a bunch of these site collection app catalogs. What I could do is add an optional new flag to the cmdlet to bypass this extra validation check which we've added last year. With that though, it would happen again that it returns URLs that have been renamed and no longer exist, but it would be back at the speeds you have experienced before. Would that help you out? — Reply to this email directly, view it on GitHub<#2986 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWBIXFKMKW6KLWE566CB5GLXBFHDHANCNFSM6AAAAAAWVR6GKM>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[KoenZomers]

The option will be added through PR #3025

[gautamdsheth]

Closing this , the PR is now merged. Will be available in the nightly builds tomorrow.