Sp-dev-docs: Apps in Site Collection vs Tentant App Catalog issue

[rbarten]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

When I have a version of a SPFx solution deployed in the Site Collection App Catalog and the Tenant App Catalog. I would expect that the app in the Site Collection App Catalog will always overrule the App installed in the Tenant App Catalog.

Observed Behavior

Currently that's not the case. It 'sometimes' shows the App from Tenant App Catalog (ClientSideAssets in global app catalog) and sometimes the Site Collection App Catalog version (ClientSideAssets from the current Site Collection). Didn't find any pattern in this behaviour until now. Different accounts, different session, looks random..

What we want to achieve here is that we can test a newer version of an App within a particular Site Collection.

Steps to Reproduce

• Install a SPFx app in the app catalog (for example version 0.1)
• Make a (visual) change to the app
• Install the updated SPFx with the same ID in the Site Collection app catalog (for example version 0.2)
  I Would always expect version 0.2 within the Site Collection, but I also 'sometimes' see version 0.1.

Notes:

• includeClientSideAssets is set to true
• Reproduced this with List Command Set Extensions
• Clearing Cache 'sometimes' work, but hours later the old version is shown again.
• Tested with SPFx 1.4.1

[GrahamMcMynn]

@rbarten - does this reproduce when it is more than 20 minutes after updating your site collection app catalog? This is not actionable currently, could you include your correlation ID's (from the reponse header sprequestguid) for the request to the page in both the working and failing case as well as including your main site colleciton URL?

Thanks!
Graham

[rbarten]

@mcmynn83 - The issue also occurs after more than 20 minutes after adding/updating the app in the Site Collection App Catalog.

Correlation IDs:
Incorrect: '4de17b9e-7049-6000-c76e-a756f7101af5' - Request to https://publiccdn.sharepointonline.com/vanderlande.sharepoint.com/sites/app_catalog/ClientSideAssets

Correct: 'ebef7b9e-908f-6000-ecf4-043f362f2461' - Request to https://publiccdn.sharepointonline.com/vanderlande.sharepoint.com/sites/TR00018/ClientSideAssets/

Both requests were made a few minutes after each other.
Site Collection URL used is: https://vanderlande.sharepoint.com/sites/TR00018

[GrahamMcMynn]

@rbarten - thank you for sending those correlation ID's, however, I actually need the correlation ID's for the main page load. Those are the correlation id's for getting the js file, but by the time a request is made to get the JS file it is too late (you're already using the wrong manifest which was retrieved on the main page load). Sorry about not being specific earlier.

[nikskhubani]

I too am facing this issue. For example our current SPFx version is 1.1.0.1 and the JS is deployed at

https://path.to.cdn/1.1.0.1/deploy/*

later I made a new release with version 1.1.0.2 and the JS is deployed at

https://path.to.cdn/1.1.0.2/deploy/*

When I install version 1.1.0.2, randomly it loads JS from this path;
https://path.to.cdn/1.1.0.1/deploy/* while it should NEVER load it from old path and it should always load it from this path;

https://path.to.cdn/1.1.0.2/deploy/*

[rbarten]

@mcmynn83 - New collection ID's for the request made to 'https://vanderlande.sharepoint.com/sites/TR00197/Shared%20Documents/'

Correlation ID when (old) app was loaded from Tenant App Catalog: ac3c7c9e-50e7-6000-2592-3ad072d67236

Correlation ID when correct app was loaded from Site Collection App Catalog: fe3d7c9e-b0e3-6000-dcab-9db4a36d9dd8

I noticed in the response there is some JSON with a 'manifest' entry. For the incorrect one it contains the URL to the Tenant App Catalog. Hopefully you can find a cause with this.

[GrahamMcMynn]

@rbarten - Thank you for sending those logs. I can see what the problem is from these logs. We have a bug where cache hits from the tenant app catalog block loading from the site collection app catalog unless it was already loaded as well. The way to get into this state is to have the first request to a front end be on a site collection without the site collection app catalog, and then hit the site collection app catalog site. That is why it seems random. We will get this fixed soon. For testing purposes if the cache is disabled (happens via cookie for 20 minutes after you trust a solution), it will work as expected (albeit slower). Thanks for sending the info to investigate the issue!

[GrahamMcMynn]

This issue has been fixed and it is rolling out. It is currently in 10% of our production farms and should roll out completely by the end of week. If you are still seeing this issue after this week please respond to this thread.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues