Open timmi-on-rails opened 2 years ago
@timmi-on-rails I don't think it's unreasonable to think that, however, I don't think it adds much in the way of tangible benefits here. A couple of reasons I think this:
Task
, so an injectable behaviour doesn't add anything.There could be an argument, which I think is fair, that by making this use HasTime
for its delay-task, we could allow time to slow down or pause. That could certainly have some benefits, although even that would need some very careful coding of the timeout behaviour ... not impossible, but of debateable value.
@louthy I fully agree to your second point, but only partially to your first point. While there is only one valid way to timeout in a Live Environment, there are still alternative valid implementations how to timeout in a test environment. Here is some context:
I have written a chat bot, which uses timeouts when waiting for user responses and then sends a reminder to answer the bot's message.
Now I would like to write some tests.
My plan was to time-travel with the HasTime
Test Runtime implementation and speed up test durations.
This way I don't have to wait 5 minutes for the timeout until the test passes.
@timmi-on-rails That's a reasonable request, let me have a think 👍
I was surprised that the runtime-dependent timeout implementation does not utilize the
HasTime<RT>
trait for the internal timeout task.Current version
What I expected
Is my expectation unusual?
(If not, any change is probably a breaking change, so it comes down to extending the method documentation and maybe provide a timeout2 function)