Codecov Report

Attention: Patch coverage is 83.33333% with 18 lines in your changes missing coverage. Please review.

Project coverage is 94.77%. Comparing base (9697e63) to head (7af032e).
Report is 82 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2312      +/-   ##
==========================================
- Coverage   94.82%   94.77%   -0.06%     
==========================================
  Files         104      104              
  Lines       24100    24199      +99     
==========================================
+ Hits        22853    22934      +81     
- Misses       1247     1265      +18     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@djc thanks for the review, just updated based on suggestions.

I can make this a draft but we I think it would be benefit for everyone if this is included in the next release. I expect the API and implementation to not change since the spec changes are fairly simple unless there's something we are missing? I hope not but there's clearly that risk. That being said, keeping it open requires us to depend on a fork for development, find a timely release for rustls for when our fork of quinn, and eventually og quinn itself, are ready in terms of multipath. I would rather not try to rush the rustls team pestering you all with a release when we needed it but instead allow you to include it in the next one whenever that happens, since that will most likely happen before us having a full multipath implementation we are happy with.

Let me know what you think!

ETA: codecov is unhappy, but it wants me to test the default impl of the multipath methods. Should I add these tests?

I can make this a draft but we I think it would be benefit for everyone if this is included in the next release. I expect the API and implementation to not change since the spec changes are fairly simple unless there's something we are missing? I hope not but there's clearly that risk. That being said, keeping it open requires us to depend on a fork for development, find a timely release for rustls for when our fork of quinn, and eventually og quinn itself, are ready in terms of multipath. I would rather not try to rush the rustls team pestering you all with a release when we needed it but instead allow you to include it in the next one whenever that happens, since that will most likely happen before us having a full multipath implementation we are happy with.

We make semver-compatible releases quite often and are pretty fast at doing it. I can virtually guarantee that we can get it done within like one workday of whenever your downstream work is ready, but I would really prefer to hold off on merging this until that is done.

ETA: codecov is unhappy, but it wants me to test the default impl of the multipath methods. Should I add these tests?

Seems fine to me, but maybe @ctz has a different opinion?

Also, can you file a followup issue with the next-major-release label to drop these default impls?

But I would really prefer to hold off on merging this until that is done

Understood, we'll be knocking in your door hopefully not too far in the future

can you file a followup issue with the next-major-release label to drop these default impls?

Issue created #2315 but it's pending labels (I can't add them myself)

can you file a followup issue with the next-major-release label to drop these default impls?

Issue created #2315 but it's pending labels (I can't add them myself)

Thanks, added the label.

Seems fine to me, but maybe @ctz has a different opinion?

I generally do not write tests for trivial functions just for the coverage. This PR currently looks great to me coverage-wise.

the diff looks good to me too, thanks! If you had time I feel like this could be squashed into a singular commit instead of three.

Is this ready to be flipped out of draft status w/ a rebase & squash or would folks still prefer to see this held until the end-to-end feature works with Quinn?

If the latter, could someone link up the Quinn PR it's blocked on? I took a quick scan and didn't spot an obvious candidate.

@cpu we are working on this on our own fork for now and we are not close to be done, but we are progressing: n0-computer/quinn#28 so this will be held on the condition of finalizing for a couple months. That being said I don't expect anything in this pr to change since the api is imo obvious.