I really like the approach to time-travel testing here. Injecting the clock directly into the BTContext is a very clean way to avoid flaky CI tests without having to mock global time interfaces.
Quick technical question: When a node returns 0 (Running), does the Supervisor strictly adhere to the fixed tick interval (like the 100ms in the example), or is there any built-in exponential backoff? I'm wondering how it handles CPU load if you have hundreds of trees just waiting on I/O. Really clean architecture, great work!
Hey, thanks a lot for the comment! The supervisor I added - which is a super simple one - ticks using the time.Ticker, which I assume only works with regular intervals. I think adding the built-in exponential backoff would be a nice thing to add, maybe making it go back to the node in a subtick manner. I haven't tested a super large tree or a combination thereof, but I think if the nodes can behave properly with respect to waiting some IO, it can definitely handle quite a large tree. It would be nice to add the capability to handle several trees, though. What do you think?
Quick technical question: When a node returns 0 (Running), does the Supervisor strictly adhere to the fixed tick interval (like the 100ms in the example), or is there any built-in exponential backoff? I'm wondering how it handles CPU load if you have hundreds of trees just waiting on I/O. Really clean architecture, great work!