fix(#2906): resource leak on populate children

[ianhomer]

FIx for #2906

It looks like there are some situations where the explorer tries to populate a node when it is already populated. This leads to a situation in the code where the filter reason is none, however the node has already been loaded. This in turn leads to an attempt to record the hidden stats for the reason. Since the reason however is none and the hidden_stats object has understandably not been initialised to capture stats for reason none, the following exception is thrown

Error executing vim.schedule lua callback: ...r/start/nvim-tree.lua/lua/nvim-tree/explorer/explore.lua:69: attempt to perform
 arithmetic on a nil value
stack traceback:
        ...r/start/nvim-tree.lua/lua/nvim-tree/explorer/explore.lua:69: in function 'populate_children'

The fix changes the logic so that no attempt to record hidden stats are made and the node is not reloaded. I'm assuming here that the node has been loaded OK if the path is in the nodes_by_path object. I welcome any feedback on whether that is a good assumption.

[alex-courtis]

Love your work @ianhomer
FYI as a trusted member of the nvim-tree community you can push branches etc. to the main repo.

We're back to the pre-filter logic - not populating when nodes_by_path contains: https://github.com/nvim-tree/nvim-tree.lua/pull/2856/files#diff-1b05da4f503ff1df76cfeb7ef723f260d51acd287b0486f9de0ed61b2eeaa042L21

[alex-courtis]

I'm buggered if I can replicate the telescope example, however this looks correct and might resolve #2902

[ianhomer]

I'm buggered if I can replicate the telescope example, however this looks correct and might resolve #2902

It took me a while to isolate the steps to trip this. I do have a set of repositories (that I can't share) and it would happen every time I did the steps to reproduce. I ended up deleting stuff to find the minimal set to get the error, but may be I isolated steps for my env only. It feels like a race condition and perhaps it's also dependent on hardware performance. I just tested the steps to reproduce again and I do still get the error on the commit before this fix merged.

I've also verified that the error doesn't happen for me on the latest release (after this fix merged), so looks good to me.

[alex-courtis]

It feels like a race condition and perhaps it's also dependent on hardware performance. I just tested the steps to reproduce again and I do still get the error on the commit before this fix merged.

Ah... you might be referring to this shameful hack:

nvim-tree.lua/lua/nvim-tree/explorer/init.lua

Line 447 in cd9c6db

local event_running = false

I've also verified that the error doesn't happen for me on the latest release (after this fix merged), so looks good to me.

Sounds like we've fixed the symptom at least. Let's monitor.

[alex-courtis]

I'm hoping we can get rid of that ineffective lock during https://github.com/orgs/nvim-tree/projects/1