[BUG] get-pnpretentionlabel on a list is giving a warning that there is no label found for the list despite one being set

[warrenstark]

Reporting an Issue or Missing Feature

When using get-pnpretentionlabel for a list it will consistently return that there is no label found for the specified list/library.

Set-pnpretentionlabel and reset-pnpretentionlabel both work for the same library.

Expected behavior

I expect that after I set via set-pnpretentionlabel or via sharepoint library page that I would be able to see the default label I set returned.

Actual behavior

Example behaviour

connect-pnponline -url $siteurl -ClientId $clientid -CertificateBase64Encoded $encodedpf -tenantname $tenantname

---- currently, no label exists on the library
get-pnpretentionLabel -List "Legacy VC Interop Library"
WARNING: No label found for the specified list/library.

--- library retention label is set to a label that is valid for tenant
set-pnpretentionLabel -List "Legacy VC Interop Library" -Label "2 years"

--- time is allowed to pass, and the get-pnpretentionlabel is checked again
get-pnpretentionLabel -List "Legacy VC Interop Library"
WARNING: No label found for the specified list/library.

Steps to reproduce behavior

Please see above for actual

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

3.1.0

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

Windows

[reshmee011]

I tested using nightly version 3.1.180 and it's working. Please test against the nightly PnP PowerShell module.

[warrenstark]

@reshmee011 I've tried it with 3.1.188 now and same issue.

I'll attempt today to try in a different tenant and brand new site. Also will try with different auth method, using app ID and certificate currently.

[warrenstark]

Unfortunately not working with a different tenant either. Tested with new registration of a PNP app in that tenant and tested with both a group and a standard communication site in that tenant.

Going to grab a fiddler trace of it to see if anything obvious stands out.

[warrenstark]

So the set looks great in fiddler

POST /sites/PNPLabelTest2/_api/SP.CompliancePolicy.SPPolicyStoreProxy.SetListComplianceTag HTTP/1.1
Host: devteamtelstra.sharepoint.com

and textview of this is
{"listUrl":"/sites/PNPLabelTest2/Shared Documents","complianceTagValue":"2 Month retention","blockDelete":true,"blockEdit":false,"syncToItems":false}

so exactly what I expect to see in that call

In the get-pnpretentionlabel call I see
1 - get list by title GET /sites/PNPLabelTest2/_api/web/lists/getbytitle('Documents') HTTP/1.1 - worked fine
2 - find the root folder of the list GET /sites/PNPLabelTest2/_api/Web/Lists(guid'7839e64e-57ec-4f30-b1e0-a0cf4d18b3c8')?$select=Id%2cOnQuickLaunch%2cRootFolder&$expand=RootFolder HTTP/1.1
3 - then a call to GetListComplianceTag GET /sites/PNPLabelTest2/_api/SP.CompliancePolicy.SPPolicyStoreProxy.GetListComplianceTag(listUrl='/sites/PNPLabelTest2/Shared%20Documents') HTTP/1.1

which gives a response

{"odata.null":true}

so, sharepoint API looks like it's returning null, and to me it's looking like a valid call (to my relatively amateur reading!)

If we can see that that API's behaving differently in other tenants (like yours @reshmee011) I can go ahead with raising SR's for our tenant as our tenants might be all looking to be bugged.

[warrenstark]

I've raised an SR in our dev tenant for the getListComplianceTag behaviour.