0

I am building an error handling for my rest application which uses RestSharp (Version 108.0.2) for the communication. Lets say the server accepts http-requests on port 6543 and https-requests on port 3456. When I now use http://myServer:3456 (which generates an error like expected) I get a TaskCanceledException and the CancellationToken.IsCancellationRequested is true, so it looks like the user set the CancellationToken to true, but he did not. So why is it this way and can I get a better error description which is more explaining for non-programmers or at least get a difference between manual cancellation and wrong protocol, so I can translate this to the user?

For clarification I initialize the Client this way:

RestClientOptions options = new RestClientOptions()
{
    BaseUrl = new Uri(serviceUrl),
    PreAuthenticate = false,
    Timeout = cTimeout,
    UseDefaultCredentials = globalSettings.AuthMechanism != AuthMechanism.Basic,
    UserAgent = $"{Assembly.GetExecutingAssembly().GetName().Name}/{Assembly.GetExecutingAssembly().GetName().Version}"
};
RestClient = new RestClient(options);

So there is no cancellation token set on my side explicitly. Not even in the requests:

RestRequest request = new RestRequest($"{GlobalSettings.ApiSystemUrl}/info", Method.Get);
RestResponse result = await mRestClient.ExecuteAsync(request);

This is the raw result (in JSON) I get:

{
    "Request":
    {
        "AlwaysMultipartFormData": false,
        "MultipartFormQuoteParameters": false,
        "FormBoundary": null,
        "Parameters": [],
        "Files": [],
        "Method": 0,
        "Timeout": 0,
        "Resource": "/api/v1/info",
        "RequestFormat": 0,
        "RootElement": null,
        "OnBeforeDeserialization": null,
        "OnBeforeRequest": null,
        "OnAfterRequest": null,
        "Attempts": 1,
        "CompletionOption": 0,
        "ResponseWriter": null,
        "AdvancedResponseWriter": null
    },
    "ContentType": null,
    "ContentLength": null,
    "ContentEncoding": [],
    "Content": null,
    "StatusCode": 0,
    "IsSuccessful": false,
    "StatusDescription": null,
    "RawBytes": null,
    "ResponseUri": null,
    "Server": null,
    "Cookies": null,
    "Headers": null,
    "ContentHeaders": null,
    "ResponseStatus": 4,
    "ErrorMessage": "Eine Aufgabe wurde abgebrochen.",
    "ErrorException":
    {
        "ClassName": "System.Threading.Tasks.TaskCanceledException",
        "Message": "Eine Aufgabe wurde abgebrochen.",
        "Data": null,
        "InnerException": null,
        "HelpURL": null,
        "StackTraceString": "   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   bei RestSharp.RestClient.<ExecuteInternal>d__1.MoveNext()",
        "RemoteStackTraceString": null,
        "RemoteStackIndex": 0,
        "ExceptionMethod": "8\nThrowForNonSuccess\nmscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\nSystem.Runtime.CompilerServices.TaskAwaiter\nVoid ThrowForNonSuccess(System.Threading.Tasks.Task)",
        "HResult": -2146233029,
        "Source": "mscorlib",
        "WatsonBuckets": null
    },
    "Version": null,
    "RootElement": null
}

Exception messages are server side settings in German that I now didn't translate, but as you can see, there is no InnerException or the like on my side.

Oh and I get this information like this:

if (!result.IsSuccessful)
....

if (result.ErrorException != null)
{
    if (result.ErrorException is TaskCanceledException cancel)
    {
        if (cancel.CancellationToken.IsCancellationRequested)
        {
            errorDescription += " " + RestClientStrings.Error_CanceledByUser;
        }
        else
        {
            errorDescription += " " + RestClientStrings.Error_CanceledByTimeout;
        }
    }
}
Marcel Grüger
  • 885
  • 1
  • 9
  • 25
  • I read this as "the cancellation token I'm passing in is set to cancelled. Why?" but that doesn't make any sense. You can't cancel it unless you have the `CancellationTokenSource`. And of course there's no code in the question so there's no hope of us finding the true cause of the problem you mistakenly atribute to RestSharp. – ProgrammingLlama Oct 17 '22 at 06:22
  • @ProgrammingLlama So you did try this on your side with an https port on a funtioning server and tried to access it with http and did NOT gain this exception? THEN you would be right, but I think this is more of an issue with RestSharp in general and not a specific implementation on my side. Except this part everything works fine on my side. – Marcel Grüger Oct 17 '22 at 06:32
  • I did not try it on my side because it was not clear how to reproduce the error. That's the whole reason why you're expected to provide a [mcve]. – ProgrammingLlama Oct 17 '22 at 06:44
  • The minimal example is: Use a working implementation of RestSharp on your side and try calling a http connection on a https port. For creating an example of RestSharp you can look into the RestSharp documentation. There is nothing special on my side which could cause the error. – Marcel Grüger Oct 17 '22 at 06:53
  • I excepted an error like 'request denied by server' or something the like, but not a 'action was cancelled by the user'. – Marcel Grüger Oct 17 '22 at 06:54
  • I can't reproduce the error you're seeing. I get HttpRequestException An error occurred while sending the request. with a nested inner exception: SocketException An existing connection was forcibly closed by the remote host. - I assume you're viewing this as I am by calling `result.ThrowIfError();` – ProgrammingLlama Oct 17 '22 at 07:02
  • @ProgrammingLlama Did you use the newest version of RestSharp, 108.0.2? – Marcel Grüger Oct 17 '22 at 07:22
  • 2
    Looking at the discussion in the comments, and having questions about the issue myself, I think your expectancy of what we offer here might be off. We're just other developers that spend our free time helping others. And there are many others. So getting frustrated over us asking for details or an example will not help you get help. – JHBonarius Oct 17 '22 at 07:23
  • Yep. I did indeed. – ProgrammingLlama Oct 17 '22 at 07:23
  • Hm, then this is really a strange behaviour. Maybe it is something on the server side? I doubt it, but cannot completely rule it out. Maybe I should ask this question at GitHub and ask the developers. I just hoped, someone could say something like: 'I can comprehend it, but if you look at the property x there you can see that it is not cancelled by the user, so you can assume that it is an connection issue' or something the like. But thanks @ProgrammingLlama – Marcel Grüger Oct 17 '22 at 07:43
  • 1
    Because of my point-count, I can see that it was not "upvoted", but the downvote was retracted. Don't focus on up or downvotes: focus on getting other to understand your question and being able to reproduce it. Not only will that increase the change of them finding your issue, it might actually help you find the problem (rubber ducky-style). – JHBonarius Oct 17 '22 at 08:40

0 Answers0