Deno Occasionally Panics on 1.41.0 When Caching Dependencies about deno HOT 6 CLOSED

Apparently, that doesn't just happen with compile, but every time when Deno caches dependencies and shows their progress.

from deno.

Per std::time::SystemTime::elapsed docs:

Returns the difference from this system time to the current clock time.

This function may fail as the underlying system clock is susceptible to drift and updates (e.g., the system clock could go backwards), so this function might not always succeed. If successful, Ok(Duration) is returned where the duration represents the amount of time elapsed from this time measurement to the current time.

We should probably remove .unwrap() there and default to 0s duration there.

from deno.

Per std::time::SystemTime::elapsed docs:

Returns the difference from this system time to the current clock time.
This function may fail as the underlying system clock is susceptible to drift and updates (e.g., the system clock could go backwards), so this function might not always succeed. If successful, Ok(Duration) is returned where the duration represents the amount of time elapsed from this time measurement to the current time.

We should probably remove .unwrap() there and default to 0s duration there.

If defaulting to 0 is enough, I can create a PR for it!

from deno.

Also, it seems like docs are recommending to use Instant instead.

To measure elapsed time reliably, use Instant instead.

But Instant also has this note:

Note, however, that instants are not guaranteed to be steady. In other words, each tick of the underlying clock might not be the same length (e.g. some seconds may be longer than others). An instant may jump forwards or experience time dilation (slow down or speed up), but it will never go backwards. As part of this non-guarantee it is also not specified whether system suspends count as elapsed time or not. The behavior varies across platforms and rust versions.

Instants are opaque types that can only be compared to one another. There is no method to get “the number of seconds” from an instant. Instead, it only allows measuring the duration between two instants (or comparing two instants).

Would using Instant instead of SystemTime change the intended behaviour?

from deno.

@catuhana yes, that would work as well. This field is used for a very non-essential functionality that doesn't need to display very precise data, so anything that removes a potential panic is a good fix 👍

from deno.

Alright, thanks!

from deno.