XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Some dashboard loading issues with v6

    Scheduled Pinned Locked Moved Xen Orchestra
    2 Posts 2 Posters 18 Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • acebmxerA Offline
      acebmxer
      last edited by

      Just noticed my V6 dashboard for the XO appliance does not load... Commit - d810e

      Screenshot_20260514_172209.png

      Reboot xo and the dashboard may load or after a few refreshes it will load or partially load.

      Screenshot_20260514_172919.png

      Pool Dashboard loads...

      Screenshot_20260514_172342.png

      Screenshot_20260514_173222.png

      Screenshot_20260514_173236.png

      After some trouble shooting with my script and AI this is what we think to be the issue...

      After pulling master (at 8c00ccef / d810ea0c), @xen-orchestra/web/dist is empty after a fresh build. Turbo reports all 33 tasks successful, but the browser gets text/html for every JS chunk under /assets/ because xo-server serves / from an empty directory.

Yarn warns about unmet peer deps for @xen-orchestra/web-core@0.52.0:

pinia@^3.0.1
vue@~3.5.13
vue-router@^5.0.0
vue-i18n@^11.1.2
These appear to not be resolved correctly, likely causing Vite to produce no output while still exiting 0. The old UI is accessible at /v5.

Environment: Node 24.15.0, yarn 1.22.22, turbo 2.9.12, built from fresh clone.

      Another issue found

      After a token flush (or after any update where session tokens are cleared), xo-server logs:


TypeError: Cannot destructure property 'client' of 'token' as it is undefined.
    at Tokens._unserialize (packages/xo-server/src/models/token.mjs:16:13)
    at packages/xo-server/src/collection/redis.mjs:194:48
Root cause: collection/redis.mjs iterates xo:token:* keys but does not filter out the xo:token::indexes key, which is a Redis HASH (not a STRING). Calling GET on a hash-type key returns a WRONGTYPE error; the code receives undefined and passes it to _unserialize, which destructures it and crashes. The fix would be to skip keys containing :: when iterating token records, since those are collection index metadata, not auth token entries.
      1 Reply Last reply Reply Quote 0
      • olivierlambertO Online
        olivierlambert Vates 🪐 Co-Founder CEO
        last edited by

        Ping @Team-XO-Frontend

        1 Reply Last reply Reply Quote 0

        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

        With your input, this post could be even better 💗

        Register Login
        • First post
          Last post