Ah, very deep issue with one of the big wins of Matrix: formulas being able to pull the information they need from anywhere, barring cycles. In this case, the cumulative widget wants to see the :msg-received property of the MX model named :msg-recipient. No cycle there, but...
To make coding easy, we just say "find :msg-recipient", with no need to explain how to find it. The find utility just searches everywhere via the :parent and :kids properties, recursively. This blind search does indeed lead to a cycle, but only because it is blind; it is searching recursively everywhere, eventually back to its starting point. It gets worse. 🙂
It was not just the blind search. That blind search triggers kids rules as it goes, and those actually execute JIT to produce MX nodes to possibly satisfy the search! And even worse, as these nodes spring to life, all their properties get computed if formulaic! And observed!! But this works, except for this edge case. And this edge case is well-known.
Long before this I had seen I could write a kids formula that could cycle back on itself. But it happened rarely, and was always easy to work around by recasting some logic. But looking at this use case, and seeing where an unrelated issue is headed, I am looking at a more robust solution, one that does not require the developer to be forever stressing over recasting natural solutions to make Matrix happy. That is where libraries go wrong. So...
OK, yes, me addressing Flutter variability by forcing more parent-child exacerbates the problem, but I am leaving that as is for its stress value while I go for "robust":
Continue the blind global search, but treat cycles as acceptable "dead ends" and carry on searching.
This will likely eliminate the need to direct MX search with things like "search up". That would be hellasweet: consciously directing search is the one speed bump in MX programming. 🤞