Sp-dev-docs: SharePoint Framework custom web parts stopped rendering

[mpowney]

Category

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

Expected or Desired Behavior

Custom Web Parts that have been developed on SPFx are rendered on a modern page as expected.

Observed Behavior

On two tenants (so far) we have home pages that are not rendering our custom SPFx web parts. None of the events of the web part rendering appear to fire (i.e. internal web part logging does not show in the browser console).

When we edit the page, and then discard the changes, the web parts initialise and render as expected.

Application Customizers that place content in the header and footer placeholders, packaged in the same solution as the custom web parts, render as expected.

Observed with solutions built on SPFx v1.4, and v1.8.

Out of 6-7 customers, on different tenants, with similar solutions as each other deployed do not experience this behaviour. So far, 2 customers (and our own) tenant are experiencing this problem.

Steps to Reproduce

1. Browse to a modern page with custom SPFx web parts
2. The custom SPFx web parts do not render

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[mpowney]

Further investigation shows that the web part bundles do not load for the affected web parts on page load.

When I edit, and discard the changes to the page, the web part bundles load as expected, and the web parts render correctly

[mpowney]

Additional observation - ootb web parts (an image web part) renders correctly on first page load.

[mpowney]

When rendering the page with ?maintenancemode=true, we observe the following error, repeated the same number of times as there are custom SPFx web parts on the page:

TypeError: Cannot read property 'alias' of undefined
    at t.e._createWebPartTag (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:232)
    at t.e._getWebPartContext (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:232)
    at t._loadWebPartInMaintenanceMode (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:232)
    at t.loadWebPart (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:232)
    at t.n._reloadWebPart (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:185)
    at t.componentDidMount (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:185)
    at Wa (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:83)
    at Ba (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:83)
    at sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:83
    at Object.t.unstable_runWithPriority (sp-pages-assembly_en-au_feec4475b6f29ce96fe7c8c895026a56.js:97)

[nateforsyth]

What happens when you run your Web Part project on the tenant in the Workbench?

https://[tenantName].sharepoint.com/sites/[siteName]/_layouts/15/workbench.aspx

You need to track down what part of your code is invoking .alias within your Web Part.

I would start at your componentDidMount method.

I'd hazard a guess that your Web Part is polling the DOM looking for the presence of an HTML element that no longer exists (Microsoft have been regularly updating the DOM for SharePoint), or it's a built in library that has had something deprecated.

Wrap whatever code you've got in componentDidMount in a try/catch to try to isolate what's failing.

Other than that, it's impossible to guess your issue any further without code for context. Try updating dependencies one-by-one to see whether you can isolate it further.

Consider updating the project to SPFx 1.8.1 as there were a multitude of bug fixes.

Good luck, no doubt the actual team will be able to guide you better than I have.

[mpowney]

Hi @nateforsyth - that mention of "componentDidMount" in the stack trace isn't invoked from the custom web part code, it's part of the sp-pages-assembly-* execution stack. When this error occurs in the console, none of our custom SPFx web part bundle JS files have been loaded in to memory. The error is higher up the chain.

[mpowney]

I'm observing the same behaviour with a fresh "hello world" web part, with no changes, and no other custom components, on SPFx v1.8.2.

[nateforsyth]

@mpowney noted, are there any 404 errors in the console for .js files that can't be resolved? Are these deployed to an app catalog site collection?

[mpowney]

@nateforsyth both the customer solution, and the bare bones "hello world" solution are deployed with includeClientSideAssets enabled in package-solution.json.

No 404s, 500s, or other error HTTP code is observed in Chrome's Network tab (with disable cache enabled / disabled). All network requests are in the 200s.

[mpowney]

.../_layouts/15/workbench.aspx loads the custom web parts as expected.

[nateforsyth]

Are you using an external CDN to host your package/s? How are you deploying them to SharePoint? Are you using an App Catalog site collection?

[mpowney]

Solutions are deployed to the tenant app catalog, no CDNs are configured

[nateforsyth]

I doubt I can be of any help here. I'll leave you with this.

It's most likely unrelated, but we've been having regular issues with our SPFx Extensions and have raised a GitHub Issue for it, perhaps it might help shed some light.
https://github.com/SharePoint/sp-dev-docs/issues/3802

Good luck.

[danwale]

We're seeing this same issue as well, custom SPFx and some of the OOTB web parts just disappear from the page when published, it still renders the height of the web part container but the contents don't render and if we export the pages via PnP we can see the web parts defined. They just don't render after the pages are republished.

It's not happening in all our tenants, just our PROD one (they are running on GA release).

The OOTB Countdown Timer web part disappears as soon as a published page is refreshed, it appears while in edit mode after adding the web part but on publish it disappears. Old OOTB web parts seem to be working.

We see the same stacktrace when running the maintenancemode=true query string.

[gristy58]

We are seeing the same issue and have support case opened.

[VesaJuvonen]

Thanks for reporting. We are actively looking into this now. Please keep on reporting the issue through Premier Support channel, if you can and have that possibility to provide us more input on the scale of the issue. As this apparently also impacts oob web parts, please do report that issue through tenant admin support channels (tenant admin UIs) if you do not have a Premier Support option.

Would also love details on this issue around the scale regardless, so that we can follow up on the issue where it happens, so please do add a comment if you are impacted on this in general regardless if you have or not reported it already with other support channels. That helps everyone to see how widely issue is impacting the service. Thx.

[ColinGardner]

Same problem here, none of our custom SPFx Web Parts are rendering. Neither are those from Plumsail which provides our forms technology, so basically we have had to halt business until this gets sorted. Please make that soon!

[prawnz]

Same problem here.. we even identified that the recent introduced OOTB spfx webparts like Embed, Countdown Timer, Divider, Weather, Markdown, Code Snippet is getting affected. Best of all these are provided by Microsoft. We have a Sev A with Microsoft at the moment so don't know how will they identify how to debug the issue.

[VesaJuvonen]

issue is being acknowledged, but no ETA for the fix at this point. Seems luckily only impact subset of tenants. Technical root cause analyses is still in progress, but advancing.

[gristy58]

Hope it’s fixed by the morning 40% of our clients offline and unable to do their business.

[VesaJuvonen]

@gristy58 - as I did not see input from you on this thread before, any change you can provide details on your situation? Tenant numbers which are impacted and where?

In general - please do provide details if you are encountering this issue, as that helps on identifying the impacted areas and scale.

[ksdaniel]

Issue is still present on our tenant.

We need to refresh 4 - 5 times before we get the webparts to work.

We can repro this with our custom webparts but also with the oob ones:

• Not working

• Working

No errors are visible in the console - but when debugging it seems we dont get the webpart files from the office cdn (we dont use a custom cdn).

[VesaJuvonen]

Thx @ksdaniel for updating that you are seeing the issue and on the notes related on CDN.

If anyone else is experiencing this, please share your update. Priority of this issue was decreased as we only got reports of a really small number of tenants. This is exactly why we would appreciate everyone who are experiencing it, report it to use ASAP to ensure that we understand the scale of the issue. Thx.

[JacobCoder1]

Experiencing the exact same behaviour across a tenancy we work on for both existing and new "HelloWorld" web parts.

And maintenance mode see the same errors.

I also find "Page Details" on modern pages throws infinite error loop crashing the browser.

This is affecting some business critical systems and I'm disappointed in the decrease in priority.

Also, if in need of urgent fix we have deployed to classic pages for some critical pages but user's are impacted by difference in design & styling.

[danwale]

The webparts don't work for us at all, no amounts of refreshes get them to display.

The main landing page of our intranet is not working affecting up to 800 people, so we really hope this is resolved soon.

We've found some ootb webparts did work but pretty much any newer ones that have been introduced don't work and none of our custom ones work.

We also don't use a custom CDN.

[VesaJuvonen]

Thx @JacobCoder1 and @danwale for reporting your findings. These help on understanding the scope and scale of the issue, which helps in prioritization.

We are working on short term action plan to rollback some updates, but all other reports around the issue are absolutely welcome.

[baleixo77]

It should be good again. Can you please validate if this is solved ?

[VesaJuvonen]

Like @baleixo77 noted - Issue should be now resolved. Please do confirm when you have a change in the tenants which had this issue, so that we can conclude the fix internally. Thx

[gristy58]

Thank you it looks good.

I had flagged earlier with support that it seemed to be related to that
next steps button.

That’s the most useless button anyway so just delete the code for it :)

On Tue, 9 Jul 2019 at 3:52 am, Pat Miller [e-mail] wrote:

Closed #4253 https://github.com/SharePoint/sp-dev-docs/issues/4253.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/sp-dev-docs/issues/4253?email_source=notifications&email_token=AJAE4DPGWK4K4LVZ35SLPPTP6OAUTA5CNFSM4H6W7D22YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOSMGAZVI#event-2467040469,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJAE4DJIG72YKZFQL5XRZZ3P6OAUTANCNFSM4H6W7D2Q
.

>

Regards

Chris Grist

[ColinGardner]

It seems to be back to normal here as well. I hope Microsoft learn some lessons from this as this should never have happened. I can't believe that the priority for this issue was decreased because it seemed to be a localised to a few tenancies. It brought several business operations to a halt for multiple customers and I can't see anything being a higher priority than that. I think we are owed an explanation as to what went wrong, an apology and some reassurance that it won't happen again,

[patmill]

Working on getting an explanation published rather than a comment from me.

[gristy58]

Thanks Pat,

Anyone else able to try creating a new news post and go to page details?

It locks up the browser so users are unable to post new news articles.

[patmill]

(Sorry - doing some research) OK, this is the text from official post to the tenants that reported it. If you wish to view this in a more formal setting (like the tenant communication portal), you would need to call support and say something along the lines of "I believe I was impacted by SP185088 and was wondering if Support could confirm and if so...can I get it added to my SHD?"

---

Jul 8 2019 5:34PM UTC:
SP185088
Title: Web parts issue
User impact: Users were unable to view specific web parts within SharePoint Online sites.

Final status: We've confirmed that a recent client version upgrade, coupled with recent routine maintenance actions, had unveiled a latent code issue that resulted in impact. We've reverted the client version to the last functioning build and cancelled the maintenance actions. Monitoring indicates that service has been restored.
Scope of impact: Your organization affected by this event, and the problem could have potentially impact any user.
Start time: Monday, July 1, 2019, at 7:00 AM UTC
End time: Monday, July 8, 2019, at 4:47 PM UTC
Root cause: A recent client version upgrade, coupled with recent routine maintenance actions, unveiled a latent code issue that resulted in impact.
Next steps:

• We're monitoring service health and reviewing both the version update and maintenance actions to prevent similar impact from occurring in the future.
  This is the final update for the event.

[baleixo77]

@gristy58 we are currently investigating that behavior

[mpowney]

I can confirm our two customers are no longer experiencing the "custom web parts not rendering" issue.

We have seen the "Page Details locking up the browser" behaviour. It's an OOTB button, so not really under the remit of this repo, Is this being tracked elsewhere?

[baleixo77]

@mpowney i have a repro also . i can circle back here with details but the best option about tracking would be a support ticket

[VesaJuvonen]

@mpowney and @gristy58 - let’s not combine two issues on a same issue as this specific issue has been fixed and closed around empty web parts. Please report a new issue if you have any other things to report, so that your finding do not get lost and others can find them as well, if they are experiencing same behavior. Thx.

[baleixo77]

@mpowney @gristy58 not wanting to mix threads but the second issue should also be solved alreadyt. If you started a new thread about it please let me know to update there.

[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