Elaborating, this fix is natural to the current approach to progress computation. The current algorithm doesn't isolate different load trees so a given dependency being loaded, present in multiple ones, can contribute to the progress report of both trees. This implies that cycles can happen, something we hadn't add a countermeasure against yet.

The "root cause," as I see this, is precisely the whole current approach to progress reporting. There may be a better way to do it, which is more direct or freer or pathological cases.

CICD complains
'awaited': default member initializers for bit-fields requires at least '/std:c++20'
default member initializer for bit-field is a C++20 extension

I assume you have made sure that the function cannot be called / isn't called on multiple threads at once.

This function is only called with the lock held.

I'm not sure I understand what's causing cycles here, but the addition of the bool is cheap, so it's a simple fix. I assume you have made sure that the function cannot be called / isn't called on multiple threads at once.

It is thread-safe as far as data races go, but there's a random factor from said threads affecting the "stack" in the relevant code that means there's a good chance child resources will add a parent resource as a subtask, leading to an infinite loop. For example, a .mesh ends up adding a sub-task of a .tscn being considered a sub-task, and said .tscn has the subtask of loading the same mesh. This is what led to this being very random and hard to track when I investigated it and why it's not easy to make a consistent MRP for it.

Pedro claims fixing this scenario would require a redesign, and I'm not really sure I follow along the logic of the code too well to understand how it works yet, but fixing it this way is certainly better than leaving it unattended. Since the function is used only for cosmetic purposes (computing the progress), it should be a better outcome than it causing a crash from stack overflow.

Thanks!