pass a context to Transport.ConnContext

[marten-seemann]

This context is cancelled when the QUIC connection is closed, or when the QUIC handshake fails. This allows the application to easily build and garbage collect a map of active connections.

TODO:

• figure out pass a context to Transport.ConnContext #4536 (comment)

[codecov]

Codecov Report

Attention: Patch coverage is 53.84615% with 6 lines in your changes missing coverage. Please review.

Project coverage is 85.14%. Comparing base (07acaad) to head (4413c73).

Files	Patch %	Lines
server.go	40.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4536      +/-   ##
==========================================
- Coverage   85.16%   85.14%   -0.01%     
==========================================
  Files         154      154              
  Lines       14835    14841       +6     
==========================================
+ Hits        12633    12636       +3     
- Misses       1695     1698       +3     
  Partials      507      507              

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

[marten-seemann]

There's another restriction here: The context returned MUST be derived from the context passed into ConnContext.

We can:

1. Document it.
2. Document and enforce it, by attaching an internal value to the context, and checking that it exists on the returned context (and panic if not).
3. Remove this requirement. This means we'll have to pass a second context.CancelCauseFunc to the connection struct.

[sukunrt]

Can we derive a context from the context returned from transport.ConnContext?

I mean

ctx, cancel = context.WithCancelCause(s.connContext())
...
conn = s.newConn(ctx, cancel ...)

[sukunrt]

Otherwise 3 seems the nicest.

[marten-seemann]

Can we derive a context from the context returned from transport.ConnContext?

I mean

ctx, cancel = context.WithCancelCause(s.connContext())
...
conn = s.newConn(ctx, cancel ...)

I don't think that works, since we want the context we pass to ConnContext to be canceled when the connection is closed.

[marten-seemann]

Actually, we can do 3 without any major refactor. A context.ContextCancelFunc is just a fancy name for a func(error), so we can just wrap the cancel func of the original and the returned context into one function.