After the time crate removal in #260, if pulish_request_timeout is negative, then subscriptions#expire_stale_publish_requests will panic
This is because to_std outputs a Duration, which can only be unsigned (positive).
Since the input value is negative, this will fail immediately.
Here is a playground example of a request timestamp and "now" timestamp that will fail
While this issue was fairly easy to work around, I have no idea if there are any potential implications from this approach.
Nor do I know why I might have been seeing negative durations in the first place, beyond non-absolute date synchronization between server/client
Duration::from_millis is replaced with chrono::Duration::milliseconds
signed_duration_since is changed from Duration to chrono::Duration
.to_std().unwrap() is removed.
Barring the potential impacts of not expiring negative signed_duration_since values (and the reason they are negative in the first place), this seems to at least avoid panics when such values are encountered.
After the time crate removal in #260, if
pulish_request_timeoutis negative, thensubscriptions#expire_stale_publish_requestswill panic This is because to_std outputs aDuration, which can only be unsigned (positive).Since the input value is negative, this will fail immediately.
Here is a playground example of a request timestamp and "now" timestamp that will fail
While this issue was fairly easy to work around, I have no idea if there are any potential implications from this approach. Nor do I know why I might have been seeing negative durations in the first place, beyond non-absolute date synchronization between server/client
Anyway, as seen here
Duration::from_millisis replaced withchrono::Duration::millisecondssigned_duration_sinceis changed fromDurationtochrono::Duration.to_std().unwrap()is removed.Barring the potential impacts of not expiring negative
signed_duration_sincevalues (and the reason they are negative in the first place), this seems to at least avoid panics when such values are encountered.