Potențial infinite recursion on updateModalState

[seanmdalton]

Is there an existing issue for this?

• I have searched the existing open and closed issues and I checked the docs https://github.com/jokob-sk/NetAlertX/tree/main/docs

The issue occurs in the following browsers. Select at least 2.

• Firefox
• Chrome
• Edge
• Safari (unsupported) - PRs welcome
• N/A - This is an issue with the backend

Current Behavior

When only loading the main Devices page, I noticed the Loading modal spinning for an excessive period of time (30+ seconds). When I pulled up the browser console (Google Chrome), I saw 8k (and quickly counting) requests to /php/server/query_logs.php?file=execution_queue.log&nocache=1735577383548 before my browser crashed.

When inspecting these calls, I see the following output:

[2024-12-30_11-37-05]|26551019-7584-4d2f-acc5-dd59341504c9|update_api|devices,appevents
[2024-12-30_11-37-29]|615f2daf-e97d-4ab6-8928-394d14431c1f|update_api|devices,appevents

Upon digging in (and pardon some naivety here), I'm seeing an infinitely recursive function that seems to be the cause: updateModalStat()

I threw a 'return true;' before the setTimeOut function/ajax call, and it stopped entirely. Page loads fine now (but of course lacking whatever this code block is doing).

// --------------------------------------------------------              
// Updating the execution queue in in modal pop-up                              
function updateModalState() {                           
  return true;                  //  <----- I ADDED THIS FOR TESTING
  setTimeout(function() {                                                                  
      // Fetch the content from the log file using an AJAX request              
      $.ajax({                                                       
          url: '/php/server/query_logs.php?file=execution_queue.log',
          type: 'GET',                                                          
          success: function(data) {                                                       
              // Update the content of the HTML element (e.g., a div with id 'logContent')
              $('#'+modalEventStatusId).html(data);                             
                                                      
              updateModalState();                                                                                    
          },                             
          error: function() {                                            
              // Handle error, such as the file not being found                                                                                                             
              $('#logContent').html('Error: Log file not found.');
          }                                       
      });                           
  }, 2000);                           
}         

I don't fully grok the intention of this code chain/block, so I don't want to presume a fix, but I can provide any other data you think would be helpful.

I'm running Netalert in Docker, on a macvlan network, behind Traefik/TLS, and I haven't noticed any other problems. Every other page loads perfectly fine/fast.

Expected Behavior

Since I don't know the intentions of the code block, I'm not sure what the expected behavior to be. That said, I'd expect there to be potentially a pause between calls to limit load on the service, some break condition in the recursive stack, and this to not block (by not removing the modal) the load of the rest of the page.

Steps To Reproduce

1. load /devices.php
2. open dev console
3. see lots of calls?

app.conf

No response

docker-compose.yml

No response

What branch are you running?

Production

app.log

No response

Debug enabled

• I have read and followed the steps in the wiki link above and provided the required debug logs and the log section covers the time when the issue occurs.

[seanmdalton]

Just kidding. This didn't actually fix anything. I'll keep digging

[seanmdalton]

Maybe I understand a bit more of what's happening. Potentially an execution queue contention? I can easily replicate the issue by changing a node attribute (just by updating the name, for example), clicking save, and immediately jumping back to the Devices page. This might be coinciding with a scan execution.

looking a bit more I see the actual calls are coming from 'app/front/devices.php',

function handleLoadingDialog(needsReload = false)
{                     
                           
  // console.log('needsReload:');  
  // console.log(needsReload);
                                         
  $.get('/php/server/query_logs.php?file=execution_queue.log&nocache=' + Date.now(), function(data) {

    if(data.includes("update_api|devices"))                                     
    {
      showSpinner("devices_old")
                                                                                
      setTimeout(handleLoadingDialog(true), 1000);

    } else if (needsReload)                                                     
    {                               
      location.reload(); 
    }else                             
    {                                
      hideSpinner();
    }         

  })                                                                            
                             
}

and when I watch the execution log, I'll see the 'update_api|devices' line in the file. Once I see that line drop from the log, the page loads.

There doesn't seem to be anything useful in the debug logs but I saved some examples if it'll help.

[jokob-sk]

Hey @seanmdalton ,

Thanks a lot spending this much time digging into this. I'm not 100% sure whats going on, but I'll explain how this is supposed to work. Happy to improve if you have ideas or even accept a PR :)

1. When a device is edited the api endpoint has to be updated
2. The edit triggers an update api event by adding the [2024-12-30_11-37-29]|615f2daf-e97d-4ab6-8928-394d14431c1f|update_api|devices,appevents line into the execution_queue.log
3. The backend checks the execution_queue.log every 5s (or after a delay is a scan is in progress as the scan may update the API as well).
4. After the API endpoint is updated the execution_queue.log is cleared.
5. The modal on frontend updates the state of the displayed message and the devices screen is reloaded with the fresh data

Maybe this is too convoluted, so happy to hear about possible improvements.