Runtime: HttpClient는 시간 초과 시 TaskCanceledException을 발생시킵니다.

@awithy 어떤 버전의 .NET Core를 사용하고 있습니까?

1.1

올바른 디자인이든 아니든, 설계상 OperationCanceledExceptions는 시간 초과에 대해 throw됩니다(TaskCanceledException은 OperationCanceledException임).
참조: @davidsh

우리 팀은 이것이 직관적이지 않다는 것을 알았지만 설계된 대로 작동하는 것 같습니다. 불행히도, 우리가 이것을 쳤을 때 우리는 취소 소스를 찾는 데 약간의 시간을 낭비했습니다. 이 시나리오를 작업 취소와 다르게 처리해야 하는 것은 꽤 추한 일입니다(이를 관리하기 위해 사용자 지정 처리기를 만들었습니다). 이것도 취소라는 개념을 남용한 것 같다.

빠른 응답에 다시 한번 감사드립니다.

설계상 + 지난 6개월 이상 동안 2명의 고객이 불만을 제기한 것 같습니다.
폐쇄.

@karelz 는 이 오해의 소지가 있는 예외의 영향을 받는 다른 고객으로 메모를 추가하고 있습니다. :)

정보를 주셔서 감사합니다. 상위 게시물에도 투표해 주세요(문제를 기준으로 정렬할 수 있음). 감사합니다!

올바른 설계 여부에 관계없이 설계상 OperationCanceledExceptions는 시간 초과에 대해 throw됩니다.

이것은 나쁜 디자인 IMO입니다. 요청이 실제로 취소되었는지(즉, SendAsync 에 전달된 취소 토큰이 취소되었는지) 또는 시간 초과가 경과했는지 알 수 있는 방법이 없습니다. 후자의 경우 재시도하는 것이 합리적이지만 전자의 경우에는 그렇지 않습니다. 이 경우에 딱 맞는 TimeoutException 가 있습니다. 사용하지 않으시겠습니까?

예, 이것은 또한 우리 팀을 루프에 빠뜨렸습니다. 이를 처리하기 위한 전체 스택 오버플 로 스레드가 있습니다.

며칠 전에 해결 방법을 게시했습니다. https://www.thomaslevesque.com/2018/02/25/better-timeout-handling-with-httpclient/

굉장합니다. 감사합니다.

이제 관심이 더 커짐에 따라 재개방 - StackOverflow 스레드는 이제 69개의 찬성을 얻었습니다.

cc @dotnet/ncl

어떤 소식이 있습니까? 여전히 dotnet core 2.0에서 발생합니다.

2.1 이후의 주요 문제 목록에 있습니다. 그러나 2.0/2.1에서는 수정되지 않습니다.

시간 초과가 발생했을 때 수행할 작업에는 몇 가지 옵션이 있습니다.

1. $# TaskCanceledException TimeoutException 를 던집니다.
   
   
   
   • 장점: 런타임 시 명시적 취소 작업과 타임아웃을 쉽게 구별할 수 있습니다.
   
   
   • 단점: 기술적인 주요 변경 사항 - 새로운 유형의 예외가 발생합니다.
   
   
2. $#$ TimeoutException $#$와 같은 내부 예외와 함께 TaskCanceledException 던지기
   
   
   
   • 장점: 런타임 시 명시적 취소 작업과 시간 초과를 구분할 수 있습니다. 호환되는 예외 유형입니다.
   
   
   • 열린 질문: InnerException ( TimeoutException.InnerException 로)를 보존하면서 원래의 TaskCanceledException 스택을 버리고 새 스택을 던져도 괜찮습니까? 아니면 원래 TaskCanceledException 를 보존하고 포장해야 합니까?
     
     
     
     
     
     • 새 TaskCanceledException -> 새 TimeoutException -> 원래 TaskCanceledException(null일 수 있는 원래 InnerException 포함)
     
     
     
     • 또는: 새로운 TaskCanceledException -> 새로운 TimeoutException -> 원래 TaskCanceledException.InnerException(null일 수 있음)
     
     
     
   
   
3. 시간 초과를 이유로 언급하는 메시지와 함께 TaskCanceledException 를 던집니다.
   
   
   
   • 장점: 메시지/로그에서 명시적 취소 작업과 타임아웃 구분 가능
   
   
   • 단점: 런타임에 구분할 수 없으며 "디버그 전용"입니다.
   
   
   • 열린 질문: [2]와 동일 - 원래 TaskCanceledException(및 스택)을 래핑하거나 교체해야 합니다.
   
   

원래 TaskCanceledException 의 원래 스택을 버리고 옵션 [2]에 기대고 있습니다.
@stephentoub @davidsh 생각이 있으십니까?

BTW: 시간 제한을 설정한 HttpClient.SendAsync 에서 변경 사항은 매우 간단해야 합니다.
https://github.com/dotnet/corefx/blob/30fb78875148665b98748ede3013641734d9bf5c/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L433 -L461

최상위 예외는 항상 HttpRequestException이어야 합니다. 이것이 HttpClient의 표준 API 모델입니다.

그 안에서 내부 예외로 "시간 초과"는 아마도 TimeoutException이어야 합니다. 사실, 이것을 다른 문제와 결합한다면(WebExceptionStatus와 유사한 새로운 열거형 속성을 포함하도록 HttpRequestion을 수정하는 것과 관련하여) 개발자는 해당 열거형을 확인하기만 하면 되며 내부 예외를 전혀 검사할 필요가 없습니다.

이것은 기본적으로 옵션 1)이지만 HttpClient API의 최상위 예외가 항상 HttpRequestException이라는 현재 앱 호환 API 모델을 계속 유지합니다.

참고: 다음과 같은 Stream API에서 HTTP 응답 스트림을 직접 읽을 때 "시간 초과"가 발생합니다.

```c#
var 클라이언트 = 새로운 HttpClient();
스트림 responseStream = client.GetStreamAsync(url)를 기다립니다.

int bytesRead = responseStream.ReadAsync(버퍼, 0, 버퍼 길이)를 기다립니다.
```

계속해서 System.IO.IOException 등을 최상위 예외로 던져야 합니다(실제로 이것에 대해 SocketsHttpHandler에 몇 가지 버그가 있습니다).

@davidsh 명시적 사용자 취소가 있는 경우에도 HttpRequestException 를 던지라고 제안합니까? 그들은 오늘 TaskCanceledException 를 던졌고 괜찮아 보입니다. 우리가 바꾸고 싶은 것인지 확실하지 않습니다 ...
클라이언트 측 시간 초과를 $#$ TaskCanceledException HttpRequestException 로 노출하는 것이 좋습니다.

@davidsh 명시적 사용자 취소가 있는 경우에도 HttpRequestException을 throw할 것을 제안하고 있습니까? 그것들은 오늘 TaskCanceledException을 던졌고 괜찮아 보입니다. 우리가 바꾸고 싶은 것인지 확실하지 않습니다 ...

이 질문에 답하기 전에 정확한 현재 동작을 확인하기 위해 .NET Framework를 포함한 스택의 다양한 동작을 테스트해야 합니다.

또한 경우에 따라 일부 스택에서 OperationCanceledException의 내부 예외와 함께 HttpRequestException을 throw합니다. TaskCanceledException은 OperationCanceledException의 파생 유형입니다.

명시적 사용자 취소가 있는 경우

또한 "명시적"이 무엇인지에 대한 명확한 정의가 필요합니다. 예를 들어, HttpClient.Timeout 속성을 "명시적"으로 설정하고 있습니까? 나는 우리가 아니오라고 말하는 것 같아요. CancellationTokenSource 객체에서 .Cancel()을 호출하는 것은 어떻습니까(CancellationToken 객체에 전달된 것에 영향을 미침)? "명시적"인가요? 우리가 생각할 수 있는 다른 예가 있을 것입니다.

.NET Framework는 HttpClient.Timeout 를 설정할 때도 TaskCanceledException을 발생시킵니다.

클라이언트 취소와 구현 취소를 구분할 수 없으면 둘 다 선택하십시오. 클라이언트 토큰을 사용하기 전에 파생된 토큰을 만드세요.
```c#
var 클라이언트 토큰 = ....
var innerTokenSource = CancellationTokenSource.CreateLinkedTokenSource(clientToken);

If at some point you catch **OperationCancelledException**:
```c#
try
{
     //invocation with innerToken
}
catch(OperationCancelledException oce)
{
      if(clientToken.IsCancellationRequested)
          throw; //as is, it is client initiated and in higher priority
      if(innerToken.IsCancellationRequested)
           //wrap it in HttpException, TimeoutException, whatever, wrap it in another linked token until you process all cases.
}

기본적으로 취소를 유발한 토큰을 찾을 때까지 클라이언트 토큰에서 가장 깊은 레이어까지 가능한 모든 레이어를 필터링합니다.

2.2 또는 3.0을 만드는 것에 대한 업데이트가 있습니까? @karelz @davidsh , cc @NickCraver . 나는 TimeoutException을 던지는 옵션 1) 또는 HttpRequestException에서 파생된 새로운 HttpTimeoutException을 던지기를 바랍니다. 감사 해요!

2.2 또는 3.0을 만드는 것에 대한 업데이트가 있습니까?

2.2 치고는 너무 늦어서 지난주에 출시 되었어요 ;)

2.2 치고는 너무 늦어서 지난주에 출시 되었어요 ;)

아, 쉬는 시간에 이렇게 되는군요 ;)

약간 바보 같지만 내가 찾은 가장 간단한 해결 방법은 OperationCanceledException에 대한 catch 처리기를 중첩한 다음 IsCancellationRequested 값을 평가하여 취소 토큰이 시간 초과 또는 실제 세션 중단의 결과인지 여부를 확인하는 것입니다. 분명히 API 호출을 수행하는 논리는 비즈니스 논리 또는 서비스 계층에 있을 수 있지만 단순성을 위해 예제를 통합했습니다.

````샤프
[HttpGet]
공개 비동기 작업인덱스(CancellationToken 취소 토큰)
{
노력하다
{
// 이것은 일반적으로 컨트롤러 자체가 아닌 비즈니스 로직 또는 서비스 계층에서 수행되지만 단순성을 위해 여기에서 요점을 설명합니다.
노력하다
{
//HttpClient 인스턴스에 HttpClientFactory 사용
var httpClient = _httpClientFactory.CreateClient();

        //Set an absurd timeout to illustrate the point
        httpClient.Timeout = new TimeSpan(0, 0, 0, 0, 1);

        //Perform call that requires special timeout logic                
        var httpResponse = await httpClient.GetAsync("https://someurl.com/api/long/running");

        //... (if GetAsync doesn't fail, handle the response as desired)
    }
    catch (OperationCanceledException innerOperationCanceled)
    {
        //If a canceled token exception occurs due to a timeout, "IsCancellationRequested" should be false
        if (cancellationToken.IsCancellationRequested)
        {
            //Bubble exception to global handler
            throw innerOperationCanceled;
        }
        else
        {
            //... (perform timeout logic here)
        }                    
    }                

}
catch (OperationCanceledException operationCanceledEx)
{
    _logger.LogWarning(operationCanceledEx, "Request was aborted by the end user.");
    return new StatusCodeResult(499);
}
catch (Exception ex)
{
    _logger.LogError(ex, "An unexepcted error occured.");
    return new StatusCodeResult(500);
}

}
````

이 시나리오를 보다 우아하게 처리하는 방법에 대한 다른 기사를 보았지만 모두 파이프라인 등을 파헤쳐야 합니다. 이 접근 방식이 완벽하지 않다는 것을 알고 있습니다. 미래에 실제 시간 초과 예외에 대한 더 나은 지원이 있기를 바랍니다. 풀어 주다.

http 클라이언트로 작업하는 것은 완전히 최악입니다. HttpClient를 삭제하고 처음부터 다시 시작해야 합니다.

약간 바보 같지만 내가 찾은 가장 간단한 해결 방법은 OperationCanceledException에 대한 catch 처리기를 중첩한 다음 IsCancellationRequested 값을 평가하여 취소 토큰이 시간 초과 또는 실제 세션 중단의 결과인지 여부를 확인하는 것입니다. 분명히 API 호출을 수행하는 논리는 비즈니스 논리 또는 서비스 계층에 있을 수 있지만 단순성을 위해 예제를 통합했습니다.

[HttpGet]
public async Task<IActionResult> Index(CancellationToken cancellationToken)
{
  try
  {
      //This would normally be done in a business logic or service layer rather than in the controller itself but I'm illustrating the point here for simplicity sake
      try
      {
          //Using HttpClientFactory for HttpClient instances      
          var httpClient = _httpClientFactory.CreateClient();

          //Set an absurd timeout to illustrate the point
          httpClient.Timeout = new TimeSpan(0, 0, 0, 0, 1);

          //Perform call that requires special timeout logic                
          var httpResponse = await httpClient.GetAsync("https://someurl.com/api/long/running");

          //... (if GetAsync doesn't fail, handle the response as desired)
      }
      catch (OperationCanceledException innerOperationCanceled)
      {
          //If a canceled token exception occurs due to a timeout, "IsCancellationRequested" should be false
          if (cancellationToken.IsCancellationRequested)
          {
              //Bubble exception to global handler
              throw innerOperationCanceled;
          }
          else
          {
              //... (perform timeout logic here)
          }                    
      }                

  }
  catch (OperationCanceledException operationCanceledEx)
  {
      _logger.LogWarning(operationCanceledEx, "Request was aborted by the end user.");
      return new StatusCodeResult(499);
  }
  catch (Exception ex)
  {
      _logger.LogError(ex, "An unexepcted error occured.");
      return new StatusCodeResult(500);
  }
}

이 시나리오를 보다 우아하게 처리하는 방법에 대한 다른 기사를 보았지만 모두 파이프라인 등을 파헤쳐야 합니다. 이 접근 방식이 완벽하지 않다는 것을 알고 있습니다. 미래에 실제 시간 초과 예외에 대한 더 나은 지원이 있기를 바랍니다. 풀어 주다.

우리가 이 끔찍한 코드를 작성해야 하는 것은 절대적으로 골치 아픈 일입니다. HttpClient는 Microsoft에서 만든 가장 누출되는 추상화입니다.

시간 초과에 대한 보다 구체적인 예외 정보를 포함하지 않는 것이 근시안적으로 보인다는 데 동의합니다. 사람들이 실제 시간 초과를 취소된 토큰 예외와 다르게 처리하기를 원하는 아주 기본적인 것 같습니다.

http 클라이언트로 작업하는 것은 완전히 최악입니다. HttpClient를 삭제하고 처음부터 다시 시작해야 합니다.\

그것은 별로 도움이 되지 않거나 건설적인 피드백 @dotnetchris 입니다. 고객과 MSFT 직원은 모두 더 나은 것을 만들기 위해 여기 있으며 @karelz 와 같은 사람들은 여전히 ​​고객 피드백에 귀를 기울이고 개선하려고 노력하고 있습니다. 그들이 공개적으로 개발을 해야 한다는 요구 사항은 없으며, 그들의 선의를 부정적으로 불태우지 않도록 합시다. 그렇지 않으면 그들이 공을 가지고 집에 가기로 결정할 수 있으며, 이는 커뮤니티에 더 나쁠 것입니다. 감사 해요! :)

예상 동작을 가진 HttpClient2(임시 이름)를 만들고 설명서에서 "HttpClient는 더 이상 사용되지 않습니다. HttpClient2를 사용하십시오"라고 알리고 둘 사이의 차이점을 설명하는 것이 좋습니다.

이렇게 하면 .NetFramework에 주요 변경 사항이 삽입되지 않습니다.

HttpClient는 예외 발생을 기반으로 해서는 안 됩니다. 인터넷 호스트를 사용할 수 없는 것은 예외가 아닙니다. 주소의 무한한 순열을 감안할 때 실제로 예상되는 것은 예외적인 경우가 작동하는 것입니다.

나는 심지어 3년 전에 HttpClient를 사용하는 것이 얼마나 나쁜지에 대해 블로그에 글을 남겼습니다. https://dotnetchris.wordpress.com/2015/12/11/working-with-httpclient-is-absurd/

이것은 눈에 띄게 나쁜 디자인입니다.

Microsoft의 누군가가 HttpClient를 사용한 적이 있습니까? 확실히 아닌 것 같습니다.

그런 다음 이 끔찍한 API 표면 너머에는 그것의 구성과 스레딩에 관한 온갖 종류의 추상적인 누수가 있습니다. 나는 그것이 구제 가능하다는 것이 믿을 수 없고 오직 아주 새로운 것이 실행 가능한 솔루션이라는 것을 믿을 수 없습니다. HttpClient2, HttpClientSlim은 괜찮습니다.

Http 액세스는 예외를 throw하지 않아야 합니다. 항상 결과를 반환해야 하며 결과는 완료, 시간 초과, http 응답을 검사할 수 있어야 합니다. throw가 허용되어야 하는 유일한 이유는 EnsureSuccess() 를 호출하면 세계에서 예외를 throw하는 것이 좋습니다. 그러나 인터넷의 완전히 정상적인 동작에 대한 제어 흐름 처리가 없어야 합니다. 호스트 가동, 호스트 가동 중지, 호스트 시간 초과. 그 중 어느 것도 예외적이지 않습니다.

HttpClient는 예외 발생을 기반으로 해서는 안 됩니다. 인터넷 호스트를 사용할 수 없는 것은 예외가 아닙니다. 주소의 무한한 순열을 감안할 때 실제로 예상되는 것은 예외적인 경우가 작동하는 것입니다.

@dotnetchris 이 주제에 대해 많은 열정을 갖고 계신 것 같으니 시간을 내어 HttpClient2에 대해 제안된 전체 API를 작성하고 새 문제로 토론을 위해 팀에 제출하는 것이 어떻습니까?

나는 더 깊은 기술 수준에서 HttpClient를 좋거나 나쁘게 만드는 핵심 사항에 대해 자세히 알아보지 않았으므로 @dotnetchris의 의견에 추가할 것이 없습니다. MS 개발팀을 비판하는 것은 적절하지 않다고 생각하지만 처리하기 매우 간단해 보이는 상황에 대한 솔루션을 연구하는 데 몇 시간과 몇 시간을 소비하는 것이 얼마나 답답한지 이해합니다. 특정 결정/변경이 이루어진 이유를 이해하는 데 어려움을 겪는다는 것은 MS의 누군가가 문제를 해결하는 동시에 여전히 작업을 완료하고 전달하기를 바라는 것입니다.

제 경우에는 사용자 역할을 설정하기 위해 OAuth 프로세스 중에 호출하는 외부 서비스가 있으며 해당 호출이 지정된 시간 범위 내에서 시간 초과되면(불행하게도 원하는 것보다 더 많이 발생함) 보조 방법으로 되돌려야 합니다. .

실제로 누군가가 시간 초과와 취소를 구별할 수 있기를 원하는 이유를 알 수 있는 무수히 많은 다른 이유가 있습니다. 이와 같은 일반적인 시나리오에 대한 더 나은 지원이 존재하지 않는 것처럼 보이는 이유는 제가 이해하기 힘든 부분이며 MS 팀에서 추가로 생각해볼 수 있기를 진심으로 바랍니다.

@karelz 누군가의 API 제안인 3.0의 일정에 맞춰 이것을 얻으려면 무엇이 필요할까요?

이것은 API 제안에 관한 것이 아닙니다. 이것은 올바른 구현을 찾는 것입니다. 이것은 3.0 백로그에 있으며 목록에서 상당히 높습니다(HTTP/2 및 엔터프라이즈 시나리오 뒤에 있음). 우리 팀이 3.0에서 해결할 수 있는 아주 좋은 기회입니다.
물론 커뮤니티에서 누군가가 동기를 부여하면 우리도 기여를 할 것입니다.

@karelz 이 경우 커뮤니티가 어떻게 도움을 줄 수 있습니까? API 제안이 필요하다고 언급한 이유는 "시간 초과가 발생했을 때 수행할 몇 가지 옵션이 있습니다."로 시작하는 메시지에서 팀이 목록에서 선호하는 대안을 결정했는지 확신할 수 없었기 때문입니다. 당신이 방향을 결정했다면 우리는 거기에서 갈 수 있습니다. 감사 해요!

기술적으로 말하면 API 제안 질문이 아닙니다. 결정에는 API 승인이 필요하지 않습니다. 그러나 차이점을 노출하는 방법에 대해 조정해야 한다는 데 동의합니다. 약간의 토론이 있을 것입니다.
구현에서 옵션이 너무 많이 다를 것으로 기대하지 않습니다. 커뮤니티에서 도움을 원할 경우 옵션을 구현하면 98%를 얻을 수 있습니다(예외가 한 곳에서 발생하고 위에 나열된 [1]-[3] 옵션에 맞게 나중에 쉽게 변경됨).

안녕! 우리는 최근에도 이 문제를 겪었습니다. 여전히 3.0에 대한 관심이 있는지 궁금하십니까?

예, 여전히 3.0 목록에 있습니다. 3.0에서 해결될 가능성은 여전히 ​​90%입니다.

나는 오늘 이것을 만났다. 나는 HttpClient에 시간 초과를 설정했고 그것은 나에게 이것을 준다.

{System.Threading.Tasks.TaskCanceledException: A task was canceled.}
CancellationRequested = true

나는 이것이 문제가되는 시간 초과에 대해 언급하지 않기 때문에 이것이 혼란 스럽다는 것에 동의합니다.

음, 알겠습니다. 약간 혼란스럽습니다. 이 스레드의 모든 사람들은 HTTP 시간 초과가 TaskCanceledException 를 발생시킨다고 말하는 것 같지만 그게 제가 얻는 것이 아닙니다... .NET Core 2.1에서 OperationCanceledException 를 받고 있습니다...

시간 초과에 대해 OperationCanceledException을 발생시키고 싶다면 문제를 해결할 수 있지만 제대로 문서화되지 않았기 때문에 도대체 무슨 일이 일어나고 있는지 추적하는 데 몇 시간을 보냈습니다.

https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.sendasync

HttpRequestException 시간 초과로 인해 발생한다고 명확하게 명시되어 있습니다...

TaskCanceledException은 OperationCanceledException에서 파생됩니다.

@stephentoub 예, 하지만 TaskCanceledException 를 받지 못하고 OperationCanceledException 을 받습니다.

에서와 같이 TaskCanceledException 를 잡는 catch 블록은 예외를 포착하지 않습니다. 특히 OperationCanceledException 에 대한 catch 블록이 필요합니다.

저는 이제 예외 유형을 필터링하여 HTTP 시간 초과에 대해 구체적으로 테스트하고 있으며 시간 초과임을 아는 방법은 TaskCanceledException 이 아닌 경우입니다.

```c#
노력하다 {
(var 응답 = await s_httpClient.SendAsync(request, _updateCancellationSource.Token).ConfigureAwait(false)) 사용
return (int)response.StatusCode < 400;
}
catch (OperationCanceledException ex) when (ex.GetType() != typeof(TaskCanceledException)) {
// HTTP 타임아웃
거짓을 반환합니다.
}
catch(HttpRequestException) {
거짓을 반환합니다.
}

or alternatively this works as well, which might be better:

```c#
            try {
                using (var response = await s_httpClient.SendAsync(request, _updateCancellationSource.Token).ConfigureAwait(false))
                    return (int)response.StatusCode < 400;
            }
            catch (OperationCanceledException ex) when (ex.GetType() == typeof(OperationCanceledException)) {
                // HTTP timeout
                return false;
            }
            catch (HttpRequestException) {
                return false;
            }

음, 알겠습니다. 약간 혼란스럽습니다. 이 스레드의 모든 사람들은 HTTP 시간 초과가 TaskCanceledException 를 발생시킨다고 말하는 것 같지만 그게 제가 얻는 것이 아닙니다... .NET Core 2.1에서 OperationCanceledException 를 받고 있습니다...

시간 초과에 대해 OperationCanceledException을 발생시키고 싶다면 문제를 해결할 수 있지만 제대로 문서화되지 않았기 때문에 도대체 무슨 일이 일어나고 있는지 추적하는 데 몇 시간을 보냈습니다.

https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.sendasync

HttpRequestException 시간 초과로 인해 발생한다고 명확하게 명시되어 있습니다...

시간 초과를 명시적으로 처리하는 방법(내가 원하는 만큼 깨끗하지는 않지만 방법)을 보여주는 코드 예제를 포함하여 OperationCanceledExecption이 참조되는 실제로 여러 응답이 있기 때문에 전체 스레드를 읽었습니까?

@Hobray 예, 내가 가지고 있지 않다고 생각하는 이유는 무엇입니까? 여전히 이 스레드의 얼마나 많은 사람들이 시간 초과 시 TaskCanceledException 를 받고 있는지 설명하지 못하지만 저는 그렇지 않습니다.

귀하의 코드 예제도 보았지만 불행히도 귀하가 고려하지 않은 경쟁 조건이 있습니다. 내가 사용하고 있는 코드는 이 문제를 피하고 취소 토큰에 대한 액세스가 필요하지 않다고 게시되어 있습니다.

@mikernet 아마도 그 문구가 나를 버렸을 것입니다. 내가 가능한 경쟁 조건을 고려하지 않은 것이 맞습니다. 나는 그것이 멋진 해결책이 아니라는 것을 알고 있지만 내가 간과 한 것을 설명하고 싶다면 듣고 싶습니다.

내가 알아차린 한 가지는 컨트롤러 대 미들웨어 호출에서 시간 초과 또는 취소가 발생하는지 여부에 따라 정확한 예외가 발생하는 것으로 보인다는 것입니다. 미들웨어 호출 내부에는 TaskCanceledException 인 것 같습니다. 불행히도 나는 그 이유를 이해하기 위해 .NET Core 코드 라이브러리를 파헤칠 시간이 없지만 내가 알아차린 것입니다.

@Hobray 하하 물론입니다. 죄송합니다. 경쟁 상황에 대해 비밀스럽게 말할 의도는 없었습니다. 이동 중에 마지막 메시지를 입력하는 동안 전화를 받고 있었기 때문에 설명하기 어려웠습니다.

HttpClient 시간 초과와 취소 토큰 취소 상태를 확인하는 지점 사이에 작업 취소가 시작된 경우 솔루션의 경쟁 조건이 발생합니다. 내 상황에서는 업스트림 코드가 사용자 취소를 감지할 수 있도록 계속 버블링하려면 작업 취소 예외가 필요하므로 실제로 시간 초과된 경우에만 예외를 catch할 수 있어야 합니다. 그래서 when 를 사용하고 있습니다. 캐치를 필터링합니다. 토큰 검사 솔루션을 사용하면 처리되지 않은 OperationCanceledException 가 필터를 통과하고 프로그램이 버블링되고 충돌이 발생할 수 있습니다. 왜냐하면 누군가 업스트림에서 작업을 취소하면 TaskCanceledException 가 던져지는 것이 아니라 던질 것으로 예상하기 때문입니다. OperationCanceledException .

HttpClient 메서드를 호출하는 코드가 시간 초과와 작업 취소를 모두 처리해야 하는 경우 경쟁 조건이 발생할 때 시간 초과와 사용자 취소 간의 구별은 상황에 따라 중요 하지 않을 수 있습니다... 그러나 라이브러리 수준 코드를 작성 중이고 작업 취소 버블이 더 높은 수준에서 처리되도록 해야 하는 경우 확실히 차이가 있습니다.

당신이 말하는 것이 사실이고 호출 컨텍스트가 무엇인지에 따라 시간 초과가 다른 예외 유형을 던진다면 그것은 분명히 해결해야 할 문제처럼 보입니다. 의도된 동작이거나 그래야 하는 방법은 없습니다.

가능한 경쟁 조건에 흥미가 있습니다. 나는 그것을 고려하지 않았다. 운 좋게도 제 사용 사례에서는 큰 문제가 되지 않을 것입니다.

예외 변형에 관해서는 디버깅하는 동안 몇 번 본 것과 일치하는지 확인하기 위해 작업하고 있는 미들웨어를 벙어리로 만들 시간이 필요합니다. 어리석은 Chrome 검색주소창 사전 로드 호출은 타이밍이 적절했을 때 미들웨어에서 본 적이 있습니다. 어떤 식으로든 그것을 확실히 증명할 수 있는 간단한 예를 만들 수 있다고 생각합니다.

올바른 해결 방법이 무엇인지 아직 확실하지 않습니다.

내 솔루션은 http 시간 초과로 인해 OperationCanceledException이 발생하는 상황에서 가장 정확합니다. TaskCanceledException이 발생하고 아무도 해당 동작을 재현할 수 있는 방법을 제공하지 않은 상황을 재현할 수 없으므로 환경을 테스트하고 나와 일치하는 경우 올바른 솔루션이라고 말합니다.

일부 실행 컨텍스트에서 TaskCanceledException이 발생하면 내 솔루션이 해당 컨텍스트에 대한 범용 솔루션으로 실패하고 제안된 다른 솔루션이 "최상의" 솔루션이지만 상황에 중요하거나 중요하지 않을 수 있는 경쟁 조건이 포함된 경우 당신은 평가합니다.

분명히 큰 버그가 될 것이기 때문에 TaskCanceledExceptions가 발생한다고 주장하는 사람의 자세한 내용을 듣고 싶습니다. 나는 이것이 실제로 일어나고 있는지에 대해 다소 회의적이다.

@mikernet TaskCanceledException 또는 OperationCanceledException 가 던져졌는지 여부는 크게 관련이 없습니다. 이것은 의존해서는 안 되는 구현 세부 사항입니다. 당신이 할 수 있는 일은 OperationException ( TaskCanceledException 도 잡을 것입니다)를 잡아내고 Hobray의 코멘트(https://github.com/)에 설명된 대로 전달한 취소 토큰이 취소되었는지 확인하는 것입니다. dotnet/corefx/issues/20296#issuecomment-449510983).

@thomaslevesque 나는 이미 그 접근 방식이 문제인 이유를 언급했습니다. 그것을 다루지 않으면 귀하의 의견은별로 유용하지 않습니다. 내가 설명한 문제를 해결하지 않고 변환에 참여하기 전에 진술을 다시 해시하는 것입니다.

"구현 세부 사항"에 관해서는 - 그렇습니다. 그러나 불행히도 나는 그것에 의존해야 합니다. 그렇지 않으면 작업이 실제로 취소되었거나 시간 초과되었는지 여부를 결정할 좋은 방법이 없기 때문입니다. 설명된 경쟁 조건을 피하기 위해 두 시나리오 중 어떤 것이 발생했는지를 예외로부터 100% 결정하는 방법이 있어야 합니다. OperationCanceledException 는 이 때문에 좋지 않은 선택입니다...프레임워크에는 이미 TimeoutException 가 있어 더 나은 후보자를 만들 수 있습니다.

비동기 작업에 대한 예외는 일반적인 사용 사례가 예외의 원인을 기반으로 분기 결정을 내리는 것이라면 예외의 원인을 확인하기 위해 비동기적으로 수정할 수도 있는 다른 개체의 데이터 확인에 의존해서는 안 됩니다. 그것은 경쟁 조건 문제를 구걸하는 것입니다.

또한 예외 유형이 구현 세부 사항이라는 측면에서...저는 예외에 대해 그것이 사실이라고 생각하지 않습니다. 적어도 잘 확립된 .NET 문서 관행의 관점에서는 그렇지 않습니다. .NET Framework에서 문서에 "Y가 발생하면 예외 X가 발생합니다"라고 명시되어 있고 프레임워크가 실제로 해당 예외의 공개적으로 액세스할 수 있는 하위 클래스를 발생시키는 .NET Framework의 다른 예 를 들어 보십시오.

그럼에도 불구하고 TaskCanceledException 는 시간 초과가 아니라 사용자가 시작한 작업 취소를 위해 예약해야 합니다. 앞서 말했듯이 이미 예외가 있습니다. 라이브러리는 내부 작업 취소를 캡처하고 더 적절한 예외를 발생시켜야 합니다. 작업 취소 토큰으로 시작된 작업 취소에 대한 예외 처리기는 비동기 작업 중에 발생할 수 있는 다른 관련 없는 문제를 처리할 책임이 없습니다.

@mikernet 죄송합니다. 토론에서 그 부분을 놓쳤습니다. 예, 생각하지 못한 경쟁 조건이 있습니다. 하지만 생각보다 큰 문제는 아닐지도... 타임아웃이 발생한 후 토큰의 상태를 확인하기 전에 취소 토큰이 신호를 받으면 경쟁 조건이 발생합니다. 그렇죠? 이 경우 작업이 어쨌든 취소되는 경우 시간 초과가 발생했는지 여부는 실제로 중요하지 않습니다. 따라서 OperationCanceledException 버블이 발생하도록 하여 호출자가 작업이 성공적으로 취소되었다고 믿게 합니다. 이는 실제로 시간 초과가 발생했기 때문에 거짓말이지만 호출자는 다음을 원했기 때문에 중요하지 않습니다. 어쨌든 작업을 중단합니다.

설명된 경쟁 조건을 피하기 위해 두 시나리오 중 어떤 것이 발생했는지를 예외로부터 100% 결정하는 방법이 있어야 합니다. OperationCanceledException 는 이 때문에 좋지 않은 선택일 뿐입니다. 프레임워크에는 이미 TimeoutException 가 있어 더 나은 후보자를 만들 수 있습니다.

나는 전적으로 동의합니다. 현재의 행동은 분명히 잘못되었습니다. 내 의견으로는 그것을 고칠 수 있는 가장 좋은 방법은 @karelz 의 의견 에서 옵션 1입니다. 예, 그것은 주요 변경 사항이지만 대부분의 코드 기반이 어쨌든 이 시나리오를 올바르게 처리하지 않고 있다고 생각하므로 상황을 악화시키지는 않을 것입니다.

@thomaslevesque 글쎄요, 하지만 저는 그 문제를 해결했습니다. 일부 응용 프로그램에서는 중요하거나 중요하지 않을 수 있습니다. 제 경우에는 그렇습니다. 내 라이브러리 방법의 사용자는 작업을 취소할 때 OperationCanceledException 를 기대하지 않습니다. TaskCanceledException 를 기대하고 있으며 이를 잡아서 "안전"할 수 있어야 합니다. 취소 토큰을 확인하고 취소된 것을 확인하고 예외를 전달하면 처리기에 의해 포착되지 않고 프로그램이 충돌하는 예외를 방금 전달한 것입니다. 내 방법은 시간 초과가 발생해서는 안됩니다.

물론, 이 문제를 해결할 수 있는 방법이 있습니다...새로 래핑된 TaskCanceledException 를 던질 수 있지만 그러면 최상위 스택 추적이 손실되고 HTTP 시간 초과는 내 서비스의 작업 취소와 훨씬 다르게 처리됩니다. - HTTP 시간 초과는 이동 오랜 시간 동안 캐시에 저장되지만 작업 취소는 그렇지 않습니다. 경쟁 조건으로 인해 실제 시간 초과를 캐싱하는 것을 놓치고 싶지 않습니다.

OperationCanceledException 를 잡고 취소 토큰을 확인할 수 있을 것 같습니다. 취소된 경우 전체 프로그램 충돌을 피하기 위해 다시 던지기 전에 예외 유형을 확인하여 TaskCanceledException 인지 확인하십시오. 이러한 조건 중 하나라도 거짓이면 시간 초과여야 합니다. 이 경우 남아 있는 문제는 경합 상태가 미묘하지만 빡빡한 시간 초과가 설정된 과부하 서비스에서 분당 수천 개의 HTTP 요청이 발생하는 경우 발생합니다.

어느 쪽이든 그것은 해키이며 당신이 지적한대로 어떻게 든 해결되어야합니다.

(경합 조건은 OperationCanceledException 대신 TaskCanceledException 가 발생하는 환경에서만 발생하지만, 적어도 솔루션은 예기치 않은 예외 유형을 버블링하는 것으로부터 안전하고 발생하지 않습니다. 구현 세부 정보가 변경되는 경우에도 여전히 합리적으로 잘 작동하려면 구현 세부 정보에 의존해야 합니다.

http 시간 초과의 경우 HttpClient 에서 발생하는 시간 초과 예외는 일반 System.TimeoutException 대신 System.Net.HttpRequestException (또는 하위 항목?) 유형이 아니어야 합니까? 예를 들어, 좋은 오래된 WebClient 는 $# WebExceptionStatus.Timeout 로 설정할 수 있는 Status 속성과 함께 WebException #$를 발생시킵니다.

안타깝게도 3.0에서는 이 작업을 완료할 수 없습니다. 미래로 이동합니다.
여전히 백로그 상단에 있지만 현실적으로 3.0에서는 불가능합니다 :(.

@karelz oh no :(두 번째 회사에서 연속으로 이 문제를 겪었던 방법을 다시 게시하려고 했습니다. 내가 직접 해결하려면 3.0에 대한 PR 제출 기간이 얼마나 될까요? 건배

컨텍스트에 따라 TaskCancelledException과 OperationCancelledException을 받는 것 사이의 차이점을 보고하는 사람들과 함께 위의 많은 주석에서 무슨 일이 일어나고 있는지 정확히 추적하는 데 어려움을 겪고 있습니다. MSFT의 누구든지 이를 밝힐 수 있습니까?

@mikernet 의 이 댓글 좋아요:

에서와 같이 TaskCanceledException을 잡는 catch 블록은 예외를 catch하지 않습니다. 특히 OperationCanceledException에 대한 catch 블록이 필요합니다.

cc @davidsh @stephentoub 아마도?

TaskCanceledException은 OperationCanceledException에서 파생되며 약간의 추가 정보를 전달합니다. OperationCanceledException을 잡으면 됩니다.

@karelz 는 원래 게시한 옵션 1을 사용하여 시간 초과 예외를 발생시키면 완전히 불쾌합니까?

StackExchange.Redis와 같은 것들은 Timeout 예외에서 파생된 예외를 던집니다. 그렇기 때문에 HttpClient에 대한 Timeout 예외를 잡는 것이 좋을 것입니다...

상속이 주어진 @stephentoub 를 이해합니다. @mikernet의 아래 댓글이 제 마음을 들뜨게 합니다... 그가 설명하는 이 행동은 일종의 버그여야 하는 건가요?? 그러나 사실이라면 수정 또는 해결 방법에 영향을 미칠 것입니다…

"TaskCanceledException을 catch하는 catch 블록은 예외를 catch하지 않습니다. 특히 OperationCanceledException에 대한 catch 블록이 필요합니다."

아니면 OperationEx를 던지는 곳도 있고 TaskEx를 던지는 곳도 있다는 말씀이신가요? 아마도 사람들이 ASP 미들웨어에서 오는 것을 보고 HttpClient에서 온 것이라고 생각하는 것처럼?

@mikernet 에서 아래의 이 댓글이 제 마음을 불고 있습니다... 그가 설명하는 이 동작은 일종의 버그여야 합니까??

그게 왜 "마음이 흔들리는" 것입니까? 예외 B가 예외 A에서 파생되는 경우 B에 대한 catch 블록은 구체적으로 A인 예외를 catch하지 않습니다. 예를 들어 ArgumentNullException에 대한 catch 블록이 있는 경우 " throw new ArgumentException(...)"을 catch하지 않습니다.

아니면 OperationEx를 던지는 곳도 있고 TaskEx를 던지는 곳도 있다는 말씀이신가요?

오른쪽. 일반적으로 코드는 OCE만 가정해야 합니다. 작성 방식에 따라 일부 코드는 파생된 TCE를 발생시킬 수 있습니다. 예를 들어 TaskCompletionSource.TrySetCanceled를 통해 완료된 작업은 TaskCanceledException을 생성합니다.

Stephen, 감사합니다. 스레드의 소리에서 여러 사람이 TaskCE가 모든 곳에서 발생하고 있다는 인상을 받았습니다. 그러면 mikernet에서 언급한 동작이 의미가 없었을 것입니다... 이제 명확하게 했으니, 논리적 관찰 :)

@stephentoub , 이 지침이 어디에나 문서화되어 있습니까? 핑 @guardrex

일반적으로 코드는 OCE만 가정해야 합니다...

저는 요즘 ASP.NET 문서 세트를 작업합니다. dotnet/docs 고양이에 대한 문제 열기 ...

https://github.com/dotnet/docs/issues

@karelz 및 @davidsh 와의 구체적인 제안이 있었던 곳에서 이 대화를 다시 시작할 수 있습니까? HttpClient API 모델의 소유권이 있는 누군가가 나아갈 방향에 대한 결정을 내려야 하는 것처럼 느껴집니다. WebExceptionStatus와 유사한 새로운 열거형 속성을 포함하도록 HttpRequestion을 수정하기 위해 더 큰 리팩터링에 대한 장기적으로 보이는 주제와 함께 항상 HttpRequestException(명시적 취소 제외??)인 최상위 예외에 대한 몇 가지 논의가 있었습니다.

이 전체 문제가 필요한 실제 코드 변경과 관련하여 복잡해지는 것처럼 느껴집니다. 일부 결정을 내리기 위해 반복되어야 하는 HttpClient API 모델의 지분/소유권을 가진 다른 사람들이 있습니까? 감사합니다!

여기에 동일한 문제가 있습니다. 그러나 cancellationToken.IsCancellationRequested 가 true 를 반환합니다.

    public class TimeoutHandler : DelegatingHandler
    {
        protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            try
            {
                var response = await base.SendAsync(request, cancellationToken);
                response.EnsureSuccessStatusCode();

                return response;
            }
            catch (OperationCanceledException) when (!cancellationToken.IsCancellationRequested)
            {
                throw new TimeoutException("Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.");
            }
        }

강제로 타임아웃을 하고 있습니다. 발생한 예외는 TaskCancelledException IOException 입니다.

System.Threading.Tasks.TaskCanceledException: The operation was canceled. ---> System.IO.IOException: Unable to read data from the transport connection: A operação de E/S foi anulada devido a uma saída de thread ou a uma requisição de aplicativo. ---> System.Net.Sockets.SocketException: A operação de E/S foi anulada devido a uma saída de thread ou a uma requisição de aplicativo
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Net.Http.HttpConnection.FillAsync()
   at System.Net.Http.HttpConnection.ReadNextResponseHeaderLineAsync(Boolean foldedHeadersAllowed)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithNtConnectionAuthAsync(HttpConnection connection, HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

...

(번역된 예외 텍스트에 대해 죄송합니다. 누군가가 이것을 .NET Core에도 가져오는 것이 좋을 것이라고 생각했습니다.)

보시다시피 IsCancellationRequest 을 확인하여 다른 사람들이 제안한 대로 이 문제를 해결하려고 했지만 시간 초과 시에도 true 가 반환됩니다.

현재 구성된 시간 초과가 경과했는지 확인하기 위해 타이머를 구현하려고 합니다. 그러나 분명히 나는 죽고 싶습니다 . 이것은 끔찍한 해결 방법입니다.

안녕하세요 @FelipeTaveira ,

취소가 TimeoutHandler 의 업스트림에서 HttpClient 자체에 의해 처리되기 때문에 접근 방식이 작동하지 않습니다. 핸들러는 Timeout 가 발생할 때 HttpClient 에 의해 취소되는 취소 토큰을 받습니다. 따라서 취소 토큰이 취소되지 않았는지 확인하는 것은 HttpClient 에 의해 호출된 코드가 아니라 HttpClient 를 호출하는 코드에서만 작동합니다.

사용자 정의 핸들러와 함께 작동하도록 하는 방법은 $#$8 Timeout.InfiniteTimeSpan #$ 로 설정하고 다음과 같이 자체 핸들러에서 시간 초과 동작을 제어하여 HttpClient 의 Timeout 를 비활성화하는 것입니다. 이 기사 에 표시됨(전체 코드는 여기 )

@thomaslevesque 오, 감사합니다! 나는 귀하의 코드를 읽고 그 부분이 요청당 제한 시간 구성을 지원하는 것이라고 생각했지만 TimeoutException 도 지원해야 한다는 사실을 알지 못했습니다.

앞으로 이 문제가 해결되기를 바랍니다.

그만한 가치가 있기 때문에 TaskCanceledException 가 시간 초과 시 발생하여 혼란스럽습니다.

저는 TaskCanceledExceptions 가 이전 직장에서 생산 문제를 다룰 때 혼란의 주요 원인이었다는 것을 증명할 수 있습니다. 일반적으로 HttpClient에 대한 호출을 래핑하고 적절한 경우 TimeoutException을 던집니다.

@eiriktsarpalis 감사합니다. 우리는 5.0에서 이 문제를 해결할 계획이므로 원하는 경우 해당 기간 내에 선택할 수 있습니다. 이제 우리 팀에 합류했습니다 😇.

일년? 😵 .NET Core의 약속된 민첩성은 어디에 있습니까?

하나의 문제로 전체 프로젝트의 민첩성을 판단하는 것은 다소 ... 불공평합니다.
예, 약간 당황스럽습니다. 여전히 이 문제가 있지만 수정하기 어렵고(호환성 영향으로) 먼저 해결해야 할 더 높은 우선순위의 비즈니스 목표가 있었습니다(네트워킹에서). 역사 전반에 걸쳐 이정표의 변경 사항을 참조하십시오. 이 문제의.

BTW: 다른 많은 OSS 프로젝트와 마찬가지로 SLA나 ETA 또는 문제가 언제 수정될지에 대한 약속이 없습니다. 모든 것은 우선 순위, 다른 작업, 어려움 및 문제를 해결할 수 있는 전문가의 수에 따라 다릅니다.

하나의 문제로 전체 프로젝트의 민첩성을 판단하는 것은 다소 ... 불공평합니다.

뭐, 솔직한 질문이었다. 벌써 2년이 흘렀고 또 1년이 걸린다는 것을 보고 조금 놀랐습니다. 그래도 공격은 의미가 없습니다 🙂. 이 문제를 해결하기 위해 먼저 답변해야 하는 몇 가지 질문이 있었습니다.

타협의 세계에서 ... 나는 그것을 좋아하지 않지만 씹을 수있는 또 다른 옵션이 있습니다.

TaskCanceledException 를 계속 던질 수 있지만 CancellationToken 를 센트리 값으로 설정합니다.

c# catch(TaskCanceledException ex) when(ex.CancellationToken == HttpClient.TimeoutToken) { }

그리고 또 하나: TaskCanceledException 에서 파생된 새로운 HttpTimeoutException 를 던집니다.

그리고 또 하나: TaskCanceledException 에서 파생된 새로운 HttpTimeoutException 를 던집니다.

나는 그것이 모든 우려를 해결할 것이라고 생각합니다. 특정 시간 초과를 쉽게 포착할 수 있으며 여전히 TaskCanceledException 이므로 현재 해당 예외를 포착하는 코드는 새 예외도 포착합니다(중단 변경 없음).

그리고 또 하나: TaskCanceledException에서 파생된 새로운 HttpTimeoutException을 던집니다.

다소 보기 흉하지만 아마도 좋은 절충안일 것입니다.

그리고 또 하나: TaskCanceledException 에서 파생된 새로운 HttpTimeoutException 를 던집니다.

나는 그것이 모든 우려를 해결할 것이라고 생각합니다. 특정 시간 초과를 쉽게 포착할 수 있으며 여전히 TaskCanceledException 이므로 현재 해당 예외를 포착하는 코드는 새 예외도 포착합니다(중단 변경 없음).

음, 다음과 같은 코드를 작성하는 사람들이 _가능_합니다.

try
{
  // ...
}
catch (Exception ex) when (ex.GetType() == typeof(TaskCanceledException))
{
}

따라서 이것은 기술적으로 획기적인 변경이 될 것입니다.

또한 나는 그것이 두 세계 모두에서 약간의 최악의 상황을 가지고 있다고 생각합니다. 우리는 여전히 브레이킹 체인지가 있는 동시에 일반 TimeoutException 를 얻지 못할 것입니다.

기술적으로 획기적인 변경이 될 수 있도록 이와 같은 코드를 작성하는 사람들이 있을 수 있습니다.

FWIW, 거의 모든 변경 사항이 깨질 수 있으므로 앞으로 진행하려면 어딘가에 선을 그려야 합니다. corefx에서 우리는 더 파생된 유형을 반환하거나 던지는 것을 중단하는 것을 고려하지 않습니다.
https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/breaking-change-rules.md#exceptions

타협의 세계에서 ... 나는 그것을 좋아하지 않지만 씹을 수있는 또 다른 옵션이 있습니다.

TaskCanceledException 를 계속 던질 수 있지만 CancellationToken 를 센트리 값으로 설정합니다.

catch(TaskCanceledException ex) when(ex.CancellationToken == HttpClient.TimeoutToken)
{
}

나는 이것을 정말로 좋아한다. "못생겼다""는 것 외에 다른 단점이 있습니까? 오늘 시간 초과가 발생했을 때 ex.CancellationToken 는 무엇입니까?

"못생겼다"는 것 외에 다른 단점은 없나요?

누군가가 TimeoutToken이 전달될 수 있고 시간 초과가 발생했을 때 취소 신호로 사용될 수 있다고 생각하는 것은 정말 쉬울 것입니다. 이는 이러한 용도로 다른 곳에서 사용되는 디자인이기 때문입니다.

나는 이것을 정말로 좋아한다. "못생겼다""는 것 외에 다른 단점이 있습니까? 오늘 시간 초과가 발생했을 때 ex.CancellationToken 는 무엇입니까?

문서에서 명시적으로 언급할 수 있는 특정 예외 유형을 잡는 것보다 훨씬 덜 직관적입니다.

나는 OperationCanceledException 및 파생 유형을 고려하여 응용 프로그램 오류가 아니라 중단된 실행을 나타내는 데 익숙합니다. 시간 초과 시 HttpClient 예외가 발생하면 일반적으로 오류입니다. HTTP API에 대한 호출이 있었고 사용할 수 없었습니다. 이 동작은 예를 들어 ASP.NET Core 파이프라인 미들웨어에서 더 높은 수준에서 예외를 처리하는 동안 복잡하게 만듭니다. 이 코드는 OperationCanceledException , error 및 not-error, 또는 모든 HttpClient 호출을 throw-catch 블록으로 래핑하도록 합니다.

그리고 또 하나: TaskCanceledException에서 파생된 새로운 HttpTimeoutException을 던집니다.

다소 보기 흉하지만 아마도 좋은 절충안일 것입니다.

관련된 디자인 제약과 이전 버전과의 호환성 고려 사항을 고려할 때 정말 추악한가요? 이 스레드의 누군가가 단점이 없는 분명히 우수한 솔루션을 제안했다는 것을 모릅니다(사용 또는 디자인 순도 등).

우리는 예외 유형을 변경하는 것보다 이것을 더 자세히 살펴보고 싶습니다. "어디에서 시간 초과가 발생했습니까?"라는 오랜 문제도 있습니다. -- 예를 들어, 와이어에 도달하지 않은 상태에서 요청이 시간 초과될 수 있습니다 -- 우리가 살펴봐야 하고 솔루션은 우리가 가는 방향과 호환되어야 합니다.

우리는 예외 유형을 변경하는 것보다 이것을 더 자세히 살펴보고 싶습니다. "어디에서 시간 초과가 발생했습니까?"라는 오랜 문제도 있습니다. -- 예를 들어, 와이어에 도달하지 않은 상태에서 요청이 시간 초과될 수 있습니다 -- 우리가 살펴봐야 하고 솔루션은 우리가 가는 방향과 호환되어야 합니다.

이것이 정말로 당신이 알아야 할 사항입니까? 오류가 발생한 위치에 따라 오류를 다르게 처리하시겠습니까? 저에게는 일반적으로 시간 초과가 발생했음을 아는 것으로 충분합니다.
더 많은 작업을 수행하고 싶다면 이 변경 사항이 추가 요구 사항으로 인해 .NET 5 기차를 놓치는 것을 원하지 않습니다.wink:

@scalablecory 가 제기한 문제는 주목할 만하다고 생각하지만 이것이 더 빨리 수정되는 것을 방해해서는 안 된다는 데 동의합니다. 시간 초과 이유를 평가할 수 있도록 메커니즘을 결정할 수 있지만 이에 대한 예외 문제 수정을 지연하지 마십시오. 나중에 언제든지 Reason 속성을 예외에 추가할 수 있습니다.

@thomaslevesque에 동의합니다. 나는 전에 그것을 큰 문제로 들어 본 적이 없습니다. 어디에서 오는 것입니까?

약간의 명시적인 조치가 필요한 이유를 파헤쳐도 괜찮은 반면 일반 개발자의 경우 한 가지 처리에 대해 알고/관리해야 하는 꽤 틈새 디버깅 사례입니까?

우리는 예외 유형을 변경하는 것보다 이것을 더 자세히 살펴보고 싶습니다. "어디에서 시간 초과가 발생했습니까?"라는 오랜 문제도 있습니다. -- 예를 들어, 와이어에 도달하지 않은 상태에서 요청이 시간 초과될 수 있습니다 -- 우리가 살펴봐야 하고 솔루션은 우리가 가는 방향과 호환되어야 합니다.

여기서 의미하는 바는 HttpClient가 문제를 수정하는 것보다 올바른 시간 초과 예외 유형을 발생시키는 것이 각 HttpMessageHandler의 책임이어야 한다는 것입니다.

여기서 의미하는 바는 HttpClient가 문제를 수정하는 것보다 올바른 시간 초과 예외 유형을 발생시키는 것이 각 HttpMessageHandler의 책임이어야 한다는 것입니다.

오늘날 정의된 추상화로 그것이 어떻게 가능한지 모르겠습니다. HttpMessageHandler는 HttpClient의 시간 초과에 대해 알지 못합니다. HttpMessageHandler에 관한 한, 호출자의 취소 토큰 신호, HttpClient의 CancelPendingRequests 호출, HttpClient의 강제 제한 시간 만료 등 여러 가지 이유로 취소 요청이 있을 수 있는 취소 토큰을 전달했습니다.

이것이 정말로 당신이 알아야 할 사항입니까? 오류가 발생한 위치에 따라 오류를 다르게 처리하시겠습니까? 저에게는 일반적으로 시간 초과가 발생했음을 아는 것으로 충분합니다.

서버가 귀하의 요청을 처리했는지 아는 것이 유용합니다. 진단에도 좋습니다. 원격 서버가 시간 초과되지는 않지만 클라이언트가 시간 초과를 보고하는 것은 실망스러운 경험입니다.

@davidsh 는 더 많은 통찰력을 가질 수 있습니다.

@thomaslevesque에 동의합니다. 나는 전에 그것을 큰 문제로 들어 본 적이 없습니다. 어디에서 오는 것입니까?

최근 NCL 회의에서 제기된 문제입니다. 이것이 일을 폭로하거나 지연시킬 만큼 중요하지 않다고 결정할 수도 있지만 먼저 빠른 토론의 가치가 있습니다.

@dotnet/ncl @stephentoub 이걸 침대에 놔두자. 우리는 우리가 하는 모든 것이 미묘하게 무너질 것이라는 것을 압니다. 이것은 최악의 선택처럼 보입니다. 나는 다음과 같이 앞으로 나아갈 것을 제안합니다.

TaskCanceledException 에서 파생된 새로운 HttpTimeoutException 를 던집니다.

반대?

TaskCanceledException에서 파생된 새로운 HttpTimeoutException을 던집니다.

실제로 어떻게 합니까? 아마도 코드를 스크러빙하고 CancellationToken.ThrowIfCancellationRequested 를 호출하는 모든 위치를 찾아 다음으로 변환해야 함을 의미합니다.

c# if (token.IsCancellationRequested) throw new HttpTimeoutException(EXTRASTUFF, token);

뿐만 아니라 우리가 실제로 OperationCancelledException 를 호출할 수도 있는 명시적 장소도 있습니다.

어쨌든 모든 관련 코드를 검토할 필요가 없는 옵션이 있습니까?

어쨌든 모든 관련 코드를 검토할 필요가 없는 옵션이 있습니까?

아마도 아닐 수도 있지만 우리가 제어하지 않는 곳이 있을 수 있습니다(아직 확실하지 않음). 따라서 잠재적으로 임의의 TaskCancelledException/OperationCancelledException을 잡고 새로운 HttpTimeoutException을 다시 발생시켜야 합니다.

아마도 코드를 스크러빙하고 CancellationToken.ThrowIfCancellationRequested를 호출하는 모든 위치를 찾아 다음으로 변환해야 함을 의미합니다.

어쨌든 모든 관련 코드를 검토할 필요가 없는 옵션이 있습니까?

정확히.

핸들러에 관한 한 그들이 받는 모든 것은 CancellationToken입니다. 그들은 그 토큰이 어디서 왔는지, 누가 생성했는지 또는 취소를 요청했을 수 있는 이유를 알지 못하고 신경 쓰지 않습니다. 그들이 아는 것은 어떤 시점에서 취소가 요청될 수 있고 응답으로 취소 예외가 발생한다는 것입니다. 따라서 핸들러에서 할 일이 없습니다.

관련 CancellationTokenSource를 만들고 시간 초과를 설정하는 것은 HttpClient 자체입니다.
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L488
타임아웃은 전적으로 HttpClient 자체의 발명이며 특별한 것으로 나타난 취소 예외를 처리할 것인지 여부만 알 수 있습니다.

즉, 위에서 참조한 코드는 별도의 CancellationTokenSource로 또는 자체적으로 시간 초과 논리를 처리하고 CTS를 취소하는 것 외에도 시간 초과를 별도로 추적하도록 리팩토링해야 하며 또한 다음을 수행할 수 있는 플래그를 설정해야 합니다. 그런 다음도 확인하십시오. 여기에 추가 할당을 추가할 것이라는 점에서 이것은 유료가 아닐 가능성이 높지만 코드 관점에서는 비교적 간단합니다.

그런 다음 HttpClient의 다음과 같은 위치에 있습니다.
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L536 -L541
그리고
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L562 -L566
예외를 포착하면 특별한 경우 취소를 수행하여 시간 초과가 만료되었는지 확인하고 만료된 경우 취소의 원인이라고 가정하고 원하는 유형의 새 예외를 throw해야 합니다.

제한 시간이 만료되었는지 여부를 확인하고 만료된 경우 취소의 원인이라고 가정하고 원하는 유형의 새 예외를 throw하려면 특수한 경우 취소가 필요합니다.

HttpClient.Timeout 속성이 관련되지 않은 경우 이것은 어떻게 작동합니까? 아마도 "무한"으로 설정되어 있을 것입니다. HttpClient API(GetAsync, SendAync 등)에 직접 전달된 취소 토큰은 어떻습니까? 나는 그것이 똑같이 작동한다고 가정합니까?

HttpClient.Timeout 속성이 관련되지 않은 경우 이것은 어떻게 작동합니까?

질문을 이해하지 못하겠습니다... 여기서 말하는 유일한 시간 제한입니다. 무한으로 설정하면 이 시간 초과로 인해 취소가 발생하지 않으며 할 일이 없습니다. 우리는 이미 특수한 경우 Timeout == Infinite이며 계속해서 다음을 수행합니다.
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L481

HttpClient API(GetAsync, SendAync 등)에 직접 전달된 취소 토큰은 어떻습니까? 나는 그것이 똑같이 작동한다고 가정합니까?

우리는 우리 자신이 만든 토큰 중 하나로 전달된 모든 토큰을 결합합니다.
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L485
이전 의견에서 언급했듯이 HttpClient.Timeout에 대한 자체 처리를 추적합니다. 호출자가 시간 초과로 구성한 토큰을 전달하기로 선택한 경우 이를 특별히 처리하는 것은 호출자에게 달려 있습니다. 우리가 생각하는 한 그것은 취소 요청일 뿐입니다.

반대?

내부 예외로 TimeoutException을 래핑하는 취소 예외를 throw하는 대신 기존 TimeoutException과 "경쟁하는" 새로운 파생 예외 유형을 도입하는 이유는 무엇입니까? 목표가 소비자가 취소가 시간 초과로 인한 것인지 프로그래밍 방식으로 결정할 수 있도록 하는 것이라면 충분할까요? 새로운 표면적을 필요로 하지 않고 동일한 정보를 전달하는 것처럼 보일 것입니다.

내부 예외로 TimeoutException을 래핑하는 취소 예외를 던지는 대신 기존 TimeoutException과 "경쟁하는" 새로운 파생 예외 유형을 도입하는 이유는 무엇입니까?

편의상 대부분. 쓰기가 더 쉽고 직관적입니다.

catch(HttpTimeoutException)

~보다

catch(OperationCanceledException ex) when (ex.InnerException is TimeoutException)

즉, 시간 초과를 식별하기가 합리적으로 쉬운 한 어느 쪽이든 괜찮습니다.

TimeoutException을 내부 예외로 래핑하는 취소 예외를 던지고 있습니까?

좋은 타협점이라고 생각합니다. 이러한 종류의 시간 초과를 처리할 때 가장 큰 골칫거리였던 예외 로그를 ​​명확하게 하는 데 도움이 됩니다. 또한 기본 처리기에 의해 발생하는 시간 초과가 아니라 요청을 취소하는 HttpClient라는 사실을 더 잘 전달할 수 있습니다. 또한 주요 변경 사항이 없습니다.

분류:

• 이 시나리오를 업데이트하여 InnerException 의 TimeoutException 가 되도록 업데이트하고 시간 초과 트리거로 인한 취소를 쉽게 구별하는 로깅/진단용 메시지를 표시합니다.
• 취소를 구별하기 위해 프로그래밍 방식으로 검사할 수 있는 방법에 대한 지침으로 문서를 업데이트할 것입니다. TimeoutException 확인, 무한 Timeout $ 사용, 시간 초과 기간이 있는 CancellationToken 전달 등

여기에서 해결하려면 약간의 타협이 필요하며 이것이 기존 코드와 우수한 수준의 호환성을 제공할 것이라고 믿습니다.

내부 예외로 TimeoutException을 래핑하는 취소 예외를 던지는 대신 기존 TimeoutException과 "경쟁하는" 새로운 파생 예외 유형을 도입하는 이유는 무엇입니까?

편의상 대부분. 쓰기가 더 쉽고 직관적입니다.

catch(HttpTimeoutException)

~보다

catch(OperationCanceledException ex) when (ex.InnerException is TimeoutException)

즉, 시간 초과를 식별하기가 합리적으로 쉬운 한 어느 쪽이든 괜찮습니다.

@scalablecory 몇 시간 동안 토론을 놓친 것 같아 부끄럽습니다. 일반 LoB .NET 개발자와 이러한 유형의 의사 소통을 한 경험에 따르면 파생된 HttpTimeoutException을 잡는 것이 사람들이 이해/채택하는 것보다 훨씬 쉽습니다. 내부 예외에 예외 필터를 사용하는 것을 기억하십시오. 모든 사람이 예외 필터가 무엇인지조차 알지 못합니다.

동시에, 나는 이것이 당신이 말했듯이 확실한 승/타결 솔루션이 없는 시나리오 중 하나라는 것을 완전히 알고 있습니다.

@ericsampson 이라는 점에 동의했지만 이는 많은 기존 사용자에게 큰 변화가 될 것입니다. @scalablecory 가 언급했듯이 호환성 손상을 제한하면서 개선을 위해 타협했습니다.

예외에 대해 생각할 때 일반적으로 래핑 방식이 더 낫다고 생각합니다. OperationCanceledException에서 예외를 파생시키면 이러한 예외를 비동기식 사용에서만 사용할 수 있습니다. 그리고 심지어 그것은 작업에 빡빡합니다. 우리가 과거에 보았듯이 비동기 접근 방식의 몇 가지 진화가 있었고 작업을 구현 세부 사항으로 간주하지만 예를 들어 TimeoutException은 변경되지 않는 소켓 개념의 일부입니다.

@ericsampson 이라는 점에 동의했지만 이는 많은 기존 사용자에게 큰 변화가 될 것입니다. @scalablecory 가 언급했듯이 호환성 손상을 제한하면서 개선을 위해 타협했습니다.

내가 반드시 래핑 옵션에 동의하지 않는 것은 아니지만 - 내가 이해한 한 - 문제는 파생 옵션이 주요 변경 사항이 아니라 래핑 옵션이 더 간단하다는 점을 지적할 가치가 있다고 생각합니다. 토론의 앞부분에서 @stephentoub가 언급했듯이 파생된 예외를 throw하는 것은 corefx 지침에 따라 주요 변경 사항으로 간주되지 않습니다.

TaskCanceledException에서 HttpTimeoutException을 파생시키는 것은 이 두 예외 사이의 "is a" 관계를 위반합니다. HttpTimeoutException을 특별히 처리하지 않는 한 여전히 취소가 발생했다고 생각하도록 호출 코드를 만듭니다. 이것은 기본적으로 시간 초과인지 여부를 확인하기 위해 취소 토큰이 취소되었는지 확인하는 순간에 수행해야 하는 것과 동일한 처리입니다. 게다가 코어 라이브러리에 두 개의 타임아웃 예외가 있는 것은 혼란스럽습니다.
TaskCanceledException에 내부 예외로 TimeoutException을 추가하면 대부분의 경우 추가 정보를 제공하지 않습니다. 이미 취소 토큰을 확인하고 시간 초과 여부를 결정할 수 있기 때문입니다.

유일한 합리적인 해결책은 시간 초과 시 발생한 예외를 TimeoutException으로 변경하는 것입니다. 예, 그것은 주요 변경 사항이 될 것이지만 문제는 이미 여러 주요 릴리스에 걸쳐 있으며 주요 릴리스의 목적은 주요 변경 사항입니다.

기존 버전에 대한 문서를 업데이트하여 시간 초과가 발생할 때 메서드가 TaskCanceledException 및/또는 OperationCanceledException (두 구체적인 유형 모두 가능성이 있는 것으로 나타남)을 throw할 수 있음을 나타낼 수 있습니까? 현재 문서에는 HttpRequestException 가 시간 초과를 처리한다고 나와 있는데 이는 올바르지 않고 오해의 소지가 있습니다.

@qidydl 이 계획입니다... 시간 초과가 나타날 수 있는 모든 방법과 이를 자세히 설명하는 방법을 완전히 문서화합니다.

@alnikola , @scalablecory , @davidsh , @karelz , 그리고 이 토론/구현에 참여한 모든 사람들에게 감사드립니다. 정말 감사합니다.