Admin Page endless waiting after hitting F5

[cslegany-synerinsoft]

Bug report

Required System information

• Node.js version: v20.11.0
• NPM version: 10.2.4
• Strapi version: 5.0.6
• Database: SQLite
• Operating system: Windows
• Is your project Javascript or Typescript: Typescript

Describe the bug

The following bug only happens in production mode when the project is deployed to azure. I was unable to reproduce it locally. If you press F5 to get the entire site reloaded, sometimes you end up with an infinite loading (the blue loading spinner never ends). There're no errors in the console.

Steps to reproduce the behavior

1. Go to the admin page url in Chrome in incognito mode
2. If it loads, press F5 a few times. Sometimes the page loads, sometimes it doesn't and you'll end up with infinite loading.
3. If it doesn't load, press the Back button on the browser bar to get rid of the infinite loading. You can see the error either on the login screen or after getting logged in on the Home screen, or even in Content Manager.
4. See attached screenshot.

Expected behavior

No infinite loading.

Screenshots

package.json

"dependencies": { "@_sh/strapi-plugin-ckeditor": "^4.0.6", "@strapi/email": "5.0.6", "@strapi/plugin-cloud": "5.0.6", "@strapi/plugin-users-permissions": "5.0.6", "@strapi/strapi": "5.0.6", "better-sqlite3": "9.4.3", "moment": "^2.30.1", "mysql2": "^3.11.3", "react": "^18.0.0", "react-dom": "^18.0.0", "react-router-dom": "^6.0.0", "styled-components": "^6.0.0" }

config

All default in middlewares.ts except "frame-src" in "strapi::security" for strapi-plugin-ckeditor.

[Mastercoder424]

I can solve it assign me I have a knowledge of this loader problem

[cslegany-synerinsoft]

The issue depends on page loading speed (maybe server load balance). If you run Strapi on localhost then you won't be able to reproduce it. Here is a video captured showing the issue.

https://github.com/user-attachments/assets/990ed347-0ae4-4039-a3f8-835d14fc710d

[tprim92]

This is a serious bug and needs an immediate fix. It is impossible to use Strapi on our production environment and our customer keeps complaining about it.

[Convly]

Hey, thanks for reporting this issue.

Would it be possible to provide more information about what request is preventing the admin from loading?

If you could share screenshots from the network tab or something similar (if possible), that would help us a lot to understand what could be the issue.

[tprim92]

Nothing interesting...

[Marc-Roig]

@tprim92 can you also check in the network tab for any blocked request (not filtering by Fext/XHR but showing all requests). Also, are you using azure too? We are trying to pin point how to reproduce the issue

[tprim92]

All status responses are 200 OK. The Strapi website has been deployed to multiple environments. The faster the hosting service, the less frequently occurs the issue. I'm 100% sure that the issue isn't caused by Azure and I'd believe that an async await completes too fast.

[Marc-Roig]

Just in case, could you try running g it locally using yarn build & yarn start ? 🙏

[Marc-Roig]

also , I assume thats the case by your words , but it never hurts to ask, are you running this instance in dev mode? (yarn develop) and not production mode (yarn start) ?

[cslegany-synerinsoft]

Of course we do develop in dev mode but the Strapi instance has been tested in production mode (npm run build, npm run start) as well. The issue never happens locally, either in dev or production mode.

[derrickmehaffy]

Of course we do develop in dev mode but the Strapi instance has been tested in production mode (npm run build, npm run start) as well. The issue never happens locally, either in dev or production mode.

The reason we ask is that Strapi 5 development mode uses vite which uses a websocket in dev mode. My guess was that in dev mode the port used for that websocket was being blocked or had some kind of race condition.

If you can get it to load at all though that may not be the issue (if you run in prod mode that websocket isn't used)

Thanks for the clarification

[cslegany-synerinsoft]

Our guess is that this issue is related to speed problems. Strapi runs ultra fast on localhost and much slower on our dev/test environment in Azure. The staging environment is faster and the issue happens less frequently, but it occurs sometimes.

We tried to slow down Strapi in the local environment to reproduce the issue, but in vain. Here are the methods that we've experimented with.

• inject js code like syncWait(5000); into node_modules/.strapi/vite/deps to slow it down using the following code: const syncWait = ms => { const end = Date.now() + ms while (Date.now() < end) continue }

Result: we've managed to slow down the login screen or the content manager but the issue couldn't be reproduced.

• use a vpn and the remote DB. Result: Strapi was slower but the issue couldn't be reproduced.
• use port forwarding

However we've noticed that port forwarding fails with 429 error. See here.

[rgellen]

I have experienced very same issue with Strapi 5, and can confirm that sometimes I end up with an endless timeout. Load errors depend on internet speed and host environment speed. For example it is impossible to load the admin page when using Strapi with a vpn. It ends up with an endless timeout in all cases, meaning that a slow vpn can cause serious issues.

[Convly]

I have experienced very same issue with Strapi 5, and can confirm that sometimes I end up with an endless timeout. Load errors depend on internet speed and host environment speed. For example it is impossible to load the admin page when using Strapi with a vpn. It ends up with an endless timeout in all cases, meaning that a slow vpn can cause serious issues.

Interesting. Could you share what kind of hosting/VPN combination you're using?

It would help us a lot if we could reproduce the issue on our end.

[hoqkhanh]

I have the same issue. Do we have any fixing PR for it?

[bolg55]

Internal TID8638 having same issue

[hoqkhanh]

I have the same issue when trying to access the CMS after logging in. It loads forever with white page + loader until I clear all browser cache or reload F5 many times. I am using enterprise edition

[hoqkhanh]

I have experienced very same issue with Strapi 5, and can confirm that sometimes I end up with an endless timeout. Load errors depend on internet speed and host environment speed. For example it is impossible to load the admin page when using Strapi with a vpn. It ends up with an endless timeout in all cases, meaning that a slow vpn can cause serious issues.

Interesting. Could you share what kind of hosting/VPN combination you're using?

It would help us a lot if we could reproduce the issue on our end.

I am using the ubuntu server with node 18 and proxy pass of Apache. Not use the VPN with Enterprise Edition with Production Mode

[huandu]

I have the same issue with v5.1.0. The admin panel works on my own dev box but keeps loading when deployed.

I spent several days to debug this issue and finally find out the cause and a possible workaround. However, I don't know how to fix it properly. Need help from Strapi dev team. cc @Convly

TL; DR The <PluginsInitializer> becomes memo at runtime for unknown reason. The workaround is to make all plugins' isReady: true when calling app.registerPlugin() in plugin's admin/src/index.js|ts.

<PluginsInitializer> is designed to run all initializers of plugins. It will render <Page.Loading /> if some plugins are not ready (the isReady flag), and it will render Admin Panel after all plugins are ready. The issue here is that <PluginsInitializer> becomes a memo component for unknown reason at runtime (verified by React Dev Tool) so that it will not re-render itself after all plugins are ready.

I don't know why <PluginsInitializer> becomes memo. <PluginsInitializer> has only one child which is a memo component (the <DndProvider>). Maybe React runtime does some magic in this scenario?

[huandu]

The <PluginsInitializer> becomes memo at runtime for unknown reason.

I need to correct myself. It's not true. I just read a wrong value. The component type is $$typeof: Symbol(react.element). However, <PluginsInitializer> did work like a memo component for unknown reason. The component render function returned correct value, but React didn't refresh component tree.

[reslear]

is there a temporary solution?

hi @Convly any news?

[hoqkhanh]

it caused a big problem with the production. @derrickmehaffy is there any temporary solution for production mode? Or any plan to solve it? I am using a strapi enterprise edition which has the same issue

[reslear]

I guess I need to downgrade to strapi v4, because it's impossible to work in production.

---

Temp works is open in new incognito window

[CMatias]

I was able to reproduce this issue locally and in my case, it was the strapi cloud plugin that wasn't ready at the time the initialization was happening. After removing the plugin the issue stopped. Tested in both development and production build. Have not tested in a production deployment.

[reslear]

@CMatias you mean @strapi/plugin-cloud ? I don't have it, by the way. By the way, let's share our plugins and see if we can find a pattern.

{

  // ...

  "dependencies": {
    "@_sh/strapi-plugin-ckeditor": "^4.0.10",
    "@strapi/plugin-seo": "^2.0.2",
    "@strapi/plugin-users-permissions": "5.3.0",
    "@strapi/provider-email-sendgrid": "^5.3.0",
    "@strapi/provider-upload-aws-s3": "^5.3.0",
    "@strapi/strapi": "5.3.0",
    "better-sqlite3": "11.5.0",
    "pg": "^8.13.1",
    "react": "^18.3.1",
    "react-dom": "^18.3.1",
    "react-router-dom": "^6.22.3",
    "strapi-plugin-config-sync": "^3.0.2",
    "strapi-prometheus": "^2.1.0",
    "styled-components": "^6.1.8"
  },
  "devDependencies": {
    "@types/node": "^20.17.6",
    "@types/react": "^18.3.12",
    "@types/react-dom": "^18.3.1",
    "dotenv-cli": "^7.4.2",
    "prettier": "^3.3.3",
    "typescript": "^5.6.3"
  },
  "engines": {
    "node": ">=18.0.0 <=20.x.x",
    "npm": ">=6.0.0"
  },
  "strapi": {
    "telemetryDisabled": true
  }
}

[hoqkhanh]

After I removed @strapi/plugin-cloud, still issue

[hoqkhanh]

After a month, the Current version 5.4. Do you have any plan to solve it @derrickmehaffy ? I am using the enterprise edition. This issue causes us problems

[reslear]

Are the developers aware of this problem? Because I don't even see it in “inprogress”.

[khanhhood]

Are the developers aware of this problem? Because I don't even see it in “inprogress”.

I asked them in the premium support system for the enterprise edition that is known as the strapi team is handling it

[CMatias]

@reslear yes that was the plugin, I figured that out by applying a patch on this file of the admin dashboard. As you can see on the file, it has several mentions that it should be improved. I simply logged the plugins every time to understand which were the ones not ready and in my case it was the strapi-cloud plugin (which was ok to remove since I was not using it atm).

My solution was simply a quick fix to move forward, it warrants a deeper dive.

[reslear]

@CMatias How to debug a not working plugin, where to place console.log?

[johnspeedppc]

@reslear yes that was the plugin, I figured that out by applying a patch on this file of the admin dashboard. As you can see on the file, it has several mentions that it should be improved. I simply logged the plugins every time to understand which were the ones not ready and in my case it was the strapi-cloud plugin (which was ok to remove since I was not using it atm).

My solution was simply a quick fix to move forward, it warrants a deeper dive.

Could you give me your patch?

[CMatias]

So what I did to figure that out was:

1. Clone the Strapi repo and installed the deps
2. Go into this file and added the following on line 29

console.log('PluginsInitializer', {
    hasApluginNotReady,
    plugins,
    notReady: Object.keys(plugins).find((plugin) => plugins[plugin].isReady === false),
  });

3. I then built the core/admin Strapi package by running yarn build in /packages/core/admin - this will create a dist folder under /packages/core/admin/dist
4. Run pnpm patch @strapi/admin in my CMS repo and replace the dist by the built one (patch-package would probably work as well but I didn't test it since I'm using pnpm)
5. Commit the patch
6. Run Strapi and through the logs I've found that the strapi-cloud plugin was the one not being initialised

Just to be clear, this didn't solve anything, it just helped me debug the issue.

[khanhhood]

Any update?

[derrickmehaffy]

it caused a big problem with the production. @derrickmehaffy is there any temporary solution for production mode? Or any plan to solve it? I am using a strapi enterprise edition which has the same issue

I don't have an update that would be up to our engineering team.

For everyone in here though:

• ALL @strapi/* packages SHOULD NOT have a ^ in the version
• Please try deleting your node modules folder and any lock file
• Try removing any optional plugins
• Ensure any package cache at the OS level is cleared (yarn for example)

As far as I'm aware we haven't actually been able to reproduce this cleanly in a fresh project.

[cosminneaga]

In my case I removed @strapi/plugin-cloud and it started working, infinite loading has vanished on production mode, running on localhost.

[khanhhood]

it caused a big problem with the production. @derrickmehaffy is there any temporary solution for production mode? Or any plan to solve it? I am using a strapi enterprise edition which has the same issue

I don't have an update that would be up to our engineering team.

For everyone in here though:

• ALL @strapi/* packages SHOULD NOT have a ^ in the version
• Please try deleting your node modules folder and any lock file
• Try removing any optional plugins
• Ensure any package cache at the OS level is cleared (yarn for example)

As far as I'm aware we haven't actually been able to reproduce this cleanly in a fresh project.

I don't think it works because we tried a lot of ways. I think it's an issue from Strapi Core

[eruiz-impact]

Is there an ETA on this getting fixed? This is such a major bug that isn't being addressed.

[artsiompeshko]

+1 on this.

[derrickmehaffy]

Is there an ETA on this getting fixed? This is such a major bug that isn't being addressed.

It's currently in the engineering backlog at the moment, until one of the squads can get some time to put it in their active queue I don't have any information on when it'll be worked on.

Me and my team only do the initial triage of the issue and assign it to the backlog, our engineering team are the ones who pick it up from there.

[derrickmehaffy]

If you want some context you can see the active backlog here: https://github.com/orgs/strapi/projects/34

[khanhhood]

It's the highest priority issue. May your team should handle it first? @derrickmehaffy

[andreas-vm]

I just wanted to share that I'm also experiencing this issue both in production and locally, in development mode and in a local production build running in a Docker Compose setup.

The descriptions provided above accurately reflect what I've encountered. One additional point I can add is that it's very rare in dev mode when using the super admin user (almost impossible to reproduce), but it becomes more common when I use a limited user with a custom role (which is what all the end users will use in our setup).

When I get stuck on the loading spinner, repeated reloads don't seem to work. However, if I wait a bit, return to the tab, and then reload, it seems to load properly.

EDIT: This is running Stapi 5.4.0 with a few plugins enabled.

[CMatias]

The descriptions provided above accurately reflect what I've encountered. One additional point I can add is that it's very rare in dev mode when using the super admin user (almost impossible to reproduce), but it becomes more common when I use a limited user with a custom role (which is what all the end users will use in our setup).

I second this, it also happened during my testing - it was way harder to reproduce the issue with a Super admin.

[derrickmehaffy]

Noted thank you all, I'll do some extra testing in a prod mode application with a restricted non super admin user