Skip to content

QuicListener AcceptConnectionAsync and OperationCanceledException #78096

Closed

Description

@pepone

The QuicListener can throw OperationCanceledException when the internal TLS handshake timeout expires, this is unexpected and not documented behavior.

See

_cancellationTokenSource.CancelAfter(s_handshakeTimeout);

It would be better to wrap the OperationCanceled exception from the internal timeout in a QuicException with the ConnectionTimeout error code

You should consider fixing this along #75184

Activity

  1. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Nov 9, 2022
  2. added this to the 8.0.0 milestone on Nov 10, 2022
  3. removed
    untriagedNew issue has not been triaged by the area owner
    on Nov 10, 2022
  4. ManickaP commented on Nov 10, 2022

    @ManickaP
    Member

    Triage: we should fix this, seems easy enough and should be addressed in 8.0.

  5. self-assigned this
    on Jan 16, 2023
  6. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Feb 16, 2023
  7. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Feb 16, 2023
  8. removed their assignment
    on Feb 16, 2023
  9. rzikm commented on May 29, 2023

    @rzikm
    Member

    @ManickaP I see in the code that this scenario should throw QuicException with QuicError.ConnectionTimeout. I think we can close this issue now.

  10. ManickaP commented on May 30, 2023

    @ManickaP
    Member

    Depends where we decide to go with the exceptions. I left this open on purpose so we can discuss this.

    In some cases, it looks we're deciding to go the way of different exception types, e.g. throwing SocketException for IP related errors. But here we're doing QuicException for a timeout. So I think that the exception type here is still something we should include in the whole "exception discussion".

  11. karelz commented on Jul 18, 2023

    @karelz
    Member

    @wfurt this should also be addressed by your exception changes, shouldn't it?

  12. wfurt commented on Jul 18, 2023

    @wfurt
    Member

    no, we did not touch this one AFAIK. We should investigate separately and write some tests.

  13. self-assigned this
    on Jul 18, 2023
  14. ManickaP commented on Jul 18, 2023

    @ManickaP
    Member

    We're throwing QuicException with QuicError.ConnectionTimeout as Radek wrote in #78096 (comment)

    I'm calling this done.

  15. ghost locked as resolved and limited conversation to collaborators on Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions