Two "Uncaught (in promise)" from sp-pages-assembly on a modern page are SharePoint's own
Before you spend time on two Uncaught (in promise) exceptions whose reason is undefined and whose stack sits only inside sp-pages-assembly_*.js, load a modern page on a site with no custom code (only out-of-the-box web parts) and read the console the same way. On the tenant where this was measured both exceptions appeared there too, at the same line and column. They are SharePoint noise, not your web part.
Dvě výjimky „Uncaught (in promise)“ s důvodem undefined a stackem jen v sp-pages-assembly nejdřív porovnej se stránkou webu bez vlastního kódu. Tam se objevily také, na stejném řádku i sloupci. Jsou to výjimky SharePointu, ne tvého webpartu.
Symptom
After a release you check the console on several sites that run your SPFx web parts:
- on some sites the console is clean;
- on others it shows, on every page load and again on in-app (SPA) navigation:
Uncaught (in promise)
at <anonymous> (…/sp-client/sp-pages-assembly_1_en-us_<hash>.js:384:29687)
at <anonymous> (…/sp-client/sp-pages-assembly_1_en-us_<hash>.js:169:70370)An unhandledrejection listener shows event.reason === undefined, and no frame of your bundle appears in the stack. Because the clean sites run the same loader template, it looks like something specific to the noisy apps.
Cause
The rejections are raised inside SharePoint's page assembly. The measured A/B:
| Page | Custom code on the page | Exceptions |
|---|---|---|
| Default home page of a team site (STS#3), out-of-the-box web parts only | none (no custom web parts, no web or site custom actions; the tenant's only tenant-wide extensions are ListView Command Sets) | 2× at 384:29687 |
| Home page of a site with one SPFx web part (runtime loader), no list web part, no custom actions | one web part | 2× at 384:29687 |
| Home page of a site with one SPFx web part and an application customizer that hides the SharePoint chrome | web part + customizer | none |
The third row is why "only some apps" look affected. Assumption, not measured further: the code that rejects belongs to page chrome that the hiding customizer suppresses.
Fix
Nothing to fix in your code. Make the A/B part of the routine:
- Open a modern page with no custom web parts and no application customizers (check
_api/web/UserCustomActions,_api/site/UserCustomActionsand the Tenant Wide Extensions list) and reload it with the console open (console capture in automation tools often starts only after the first read, so reload after you attach). - Compare file name, line and column of the exceptions. Same location = SharePoint's.
- Only a frame from your own bundle, or a reason that is your error object, is worth debugging.
// paste before reload (or as early as your tool allows) to see the reasons
window.__rej = [];
addEventListener('unhandledrejection', e => window.__rej.push({ reason: String(e.reason), stack: e.reason && e.reason.stack }));