Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-5257

SolusVM: API may return an empty value rather than 0 for bandwidth usage, handle more cleanly

        Details

        • Type: Bug
        • Status: Open
        • Priority: Major
        • Resolution: Unresolved
        • Affects Version/s: 5.10.0
        • Fix Version/s: 5.11.0
        • Component/s: Modules
        • Labels:
          None

          Description

          The SolusVM module makes an API call when staff or client view the "Stats" tab. The API will return data for the API call vserver-infoall that includes different information, along with bandwidth. An example of the bandwidth returned is:

          <bandwidth>161061273600,65023881,160996249719,0</bandwidth>

          The 1st value is the bandwidth limit, the 2nd value is bandwidth used. If no bandwidth is used, we would expect this value to be 0. However, some people have been reporting a white screen error of the following:

          [2024-10-08T19:45:43.643223+00:00] general.ERROR: Uncaught Exception TypeError: "Unsupported operand types: string / int" at /var/www/html/components/modules/solusvm/solusvm.php line 2443

          {"exception":"[object] (TypeError(code: 0): Unsupported operand types: string / int at /var/www/html/components/modules/solusvm/solusvm.php:2443)"}

          The reason is that the 2nd value, the used bandwidth, is empty looking like this:

          <bandwidth>161061273600,,160996249719,0</bandwidth>

          We should add an exception where we treat no value as 0.

            Activity

            Ascending order - Click to sort in descending order
            admin Paul Phillips created issue -
            admin Paul Phillips made changes -
            Field Original Value New Value
            Rank Ranked higher
            Hide
            Permalink
            admin Paul Phillips added a comment -

            Customer was running version 1.29.15, we tested in 1.29.19 so it's possible that this was a SolusVM bug that they have since resolved. If that can be confirmed then I don't think we need to do anything, the solution is for users to upgrade SVM.

            Show
            admin Paul Phillips added a comment - Customer was running version 1.29.15, we tested in 1.29.19 so it's possible that this was a SolusVM bug that they have since resolved. If that can be confirmed then I don't think we need to do anything, the solution is for users to upgrade SVM.
            jonathan Jonathan Reissmueller made changes -
            Rank Ranked higher
            jonathan Jonathan Reissmueller made changes -
            Sprint 5.11.0 Sprint 6 [ 206 ]
            jonathan Jonathan Reissmueller made changes -
            Rank Ranked higher

              People

              • Assignee:
                Unassigned
                Reporter:
                admin Paul Phillips
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Agile