An Inconvenient PowerShell Error: “format-default : The collection has not been initialized”

For many months now, I’ve been getting our favorite kind of error – a sporadic one – when I am running PnP PowerShell which loops through the same code many times. The errors look something like this:

format-default : The collection has not been initialized. It has not been requested or the request has not been executed. It may need to be explicitly requested.
    + CategoryInfo          : NotSpecified: (:) [format-default], CollectionNotInitializedException
    + FullyQualifiedErrorId : Microsoft.SharePoint.Client.CollectionNotInitializedException,Microsoft.PowerShell.Commands.FormatDefaultCommand

In the two cases where it has plagued me the most, I’ve been using a combination of PnP PowerShell, SharePoint Online (SPO) PowerShell, and Sharegate PowerShell to reorganize content in or across several farms or tenants. It’s a potent combination. The three modules together let me do pretty much anything I want, which is great. But in many cases, my PowerShell needs to run over an extended period of time: hours or days.

Sometimes everything runs fine with no errors whatsoever. Other times, I get one of these errors every other time past certain lines. And this usually is exactly the same code, but perhaps running on a different subset of content, or on a different day, or whatever.

It’s been driving me nuts for a long time, and since I only started using PowerShell about 9 months ago, I figured there was just something I didn’t understand. Joy!

Today I think I hit pay dirt. I found an issue in Github (originally posted in 2017!) wherein many people said they have seen a similar error, across many different cmdlets.

Today, my example was a line like this:

Set-PnPListItem -Connection $rootsite -List $matterlist -Identity $thisMatter.Id -Values $matterValues

I’ve debugged that sucker every which way to Sunday. All the values in the variables are right, the connection is right, the credentials are right, and so on and so on. I’ve done try/catches, I’ve logged every bit of info I can think of to the console, you name it. There’s just no darn reason for that line to throw an error.

In that Github issue, a bunch of people have said that simply assigning the result to a variable has solved their problem, like so:

$item = Set-PnPListItem -Connection $rootsite -List $matterlist -Identity $thisMatter.Id -Values $matterValues

Can it be that simple? And why haven’t I found that Github issue before?

Well, I tried it. And the endless errors I was getting today evaporated.

The only plausible theory in that Github issue on this actually makes a bunch of sense. It’s from aronbardsley, and s/he says:

So I understand that in PowerShell – if i call a PnP function (like Add-PnpView) and I don’t store the return value in a variable, PowerShell’s default behaviour is to output the returned value in the console.

Of course, PowerShell – in doing this – attempts to read the returned object’s properties. The object returned is coming from PnP PowerShell – and upon accessing the properties of the object, PnP throws an exception saying it is uninitialised.

It only happens occasionally, making me think it’s some sort of race condition when calling functions inside the PnP framework – like the query is executed, but the function returns before it’s data is made fully available to the return object.

The thing is, the command still executes… but the error stops my entire script. I run long PowerShell scripts to make deployments to SharePoint. I can say without a doubt, this happens at least once every time i run a script – at different points in the script each time.

What that sounds like to me is some sort of incompatibility between the PnP PowerShell module and PowerShell itself. Since it’s sporadic, no one can hand that issue a reproduceable instance, even though it happens with multiple cmdlets.

I’ve learned to use PowerShell, but not to work on the code for the cmdlets. I hope this is something that gets fixed at some point, and maybe aronbardsley‘s idea is what will help that happen.

In the meantime, don’t leave those “bare” cmdlet calls in your PowerShell, and you’ll be more likely to see your script work more reliably. I’m keeping my fingers and toes crossed on this. I’ll report back here if it’s isn’t the miracle I believe it is.