Transaction stack overflow caused by sibling transactions

[raquo]

Transaction stack overflow caused by sibling transactions

[raquo]

Fixed in 281f7b0 (based on 17.0.0-M1, so to be used with Laminar v16). I will release that as M3, and port it to M2 and release that as M4.

That commit makes transactions stack safe, both in breadth and in deep nesting.

I'm also planning to add a customizable transaction depth limit to detect that kind of accidental infinite loop: raquo/Laminar#116 (otherwise that kind of bug in your code would pin the cpu and freeze the entire client app).

[raquo]

In my opinions, if we can somehow traverse the graph in truly depth first order (siblings do not create new function calls, only children do), it’d be the best.

I'm not sure if I understand what exactly you mean, but if you mean the internal mechanics of Transaction - how Transaction.run is called recursively even in case of sibling (not nested) transactions – then this is already fixed in that commit I linked. That recursion is now tail call optimized, @tailrec ensures that this recursion is rewritten into a while loop that does not blow the stack when it compiles to JS. I've added two tests, one with 20K sibling transactions, another with 20K nested transactions, that should catch any stack overflow regressions in this code.

[HollandDM]

Thank you for your quick replies on discord.

In my opinions, if we can somehow traverse the graph in truly depth first order (siblings do not create new function calls, only children do), it’d be the best. Because I do think that creating a transaction tree that go too deep is more of a bug than a coding logic, and stack overflowing in that case is a very necessary indicator.

[raquo]

Fixed in Airstream 17.0.0-M3 (binary compatible with Laminar 16) and 17.0.0-M6. See Discord #news channel for details of the releases.