Compatibility with simulated time in tokio tests

[Ralith]

When tokio::time::pause is called in a current-thread runtime, tokio will automatically skip time ahead to the next timer when all tasks are blocked. I want to use this to test whether some complex code does not issue a HTTP request over a long period, without making a test very slow and/or racy.

Unfortunately, httptest in its current form spawns a separate tokio runtime on a background thread. This prevents a test current_thread runtime from accurately judging whether any progress is being made, leading to premature advancement of the simulated clock. Could run be revised to, or grow an option to, spawn tasks in the caller's runtime instead?

See also https://docs.rs/tokio/latest/tokio/time/fn.pause.html#auto-advance, https://tokio.rs/tokio/topics/testing.

[ggriffiniii]

Thanks for opening the issue. Could you elaborate a little bit on what you're trying to do so I can better understand the goal. It sounds like you want the http client and test server to have some coordination at least with respect to how much time has elapsed. I can understand the desire to be able to manipulate time within tokio, but I would think simulating time with respect to the client initiated futures would have been sufficient to test whatever functionality was required by the client.

I'm open to seeing how it could be improved and am not opposed to the idea of extending the functionality to run the test server in a particular tokio context, but the current design is doing it's best to be agnostic to which runtime it's using. I know some of the implementation details have leaked into the API, but the goal was for the user to be unaware that the underlying server was a hyper server or anything even using tokio. The thinking was the http client should be unaware the server is even running in the same process.

[Ralith]

In facebook/buck2#922, I have a unit test which is trying to validate that a future does not issue a HTTP request by wrapping it in tokio::time::timeout and asserting that it yields an timed out error. When time is paused, the timeout always yields an error even if the future does immediately issue a HTTP request, because as soon as the client is waiting on I/O, the test runtime sees that there is no work remaining and advances the clock. If the HTTP server were running within the test runtime, then the test runtime would be able to tell that the server has work remaining, and time would not advance until the request has been handled and the client has received a response.

[ggriffiniii]

Sorry for the naive question, but this is the first I've looked into tokio's auto-advance feature. Are you saying that when auto-advance is enabled the runtime will advance simulated time even when there are futures that are waiting for pending i/o? If that's the case wouldn't any test that attaches a timeout to a network request always trigger the timeout when auto-advance is enabled. That seems surprising to me.

[Ralith]

The mechanism isn't intended to work with external I/O. When both client and server are hosted on the same runtime, then auto-advance won't be triggered while the request is in flight because the server's I/O will become ready before the client's request future yields, and vis versa for the response.