fix(quinn-proto): Avoid underflow panic in packet loss Instant calculations
#2436
+17
−9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matheus23
force-pushed
the
matheus23/fix-instant-underflow
branch
from
3f73e13 to
cec9619
Compare
|
I messed up the computation ever so slightly with a |
matheus23
force-pushed
the
matheus23/fix-instant-underflow
branch
from
cec9619 to
c53e8d6
Compare
matheus23
force-pushed
the
matheus23/fix-instant-underflow
branch
from
c53e8d6 to
592e56a
Compare
flub
added a commit
to n0-computer/quinn
that referenced
this pull request
Nov 4, 2025
Ported from quinn-rs#2436 * Remove `instant_saturating_sub` fn in favor of `Instant::saturating_duration_since` * Avoid underflow panic in packet loss `Instant` calculations
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses the failure in #2434
Subtractions from
Instantcan underflow (and thus panic), because theu64stored internally might be relative to some startup time that might be too recent.This is what caused the failure in Wasm: The instant was relative to the process startup time, in one case ~15s, but the
loss_delaywas set to ~17s in that case.Instead, this PR aims to compare the saturated difference of
nowandinfo.time_sent, and see if that's bigger thanloss_delayor not.Unfortunately I don't know of a different way of resolving this. There's no such thing as
Instant::saturating_sub, and there's noInstant::MINor similar with which it could be implemented.Even though this addresses a problem in Wasm, this case can also happen in MacOS and other platforms, but requires different, less common edge-cases to trigger.