topic Cancellation Token - Awaitable functions .NET SDK in Integration, Extension & APIs

Cancellation Token - Awaitable functions .NET SDK

catalin — Sat, 16 Nov 2024 02:00:35 GMT

Hello!

How do you control the timeout of an awaitable function, lets say:

Dim fi = Await app.GetFieldAsync(field_name) Await fi.SelectAsync(value, True)

What I would like to achieve is to define a cancellation token and use it to cancel the task after a timeout, catch the exception and retry the same task with a wait period in between.

Dim cts As CancellationTokenSource = New CancellationTokenSource cts.CancelAfter(TimeSpan.FromSeconds(100))

The reason I am asking this is that not rarely I see the application hangs out trying to make those 2 operations. Just hangs indefinitely and never return something.

Is there anyway to achieve a retry policy in case of timeout with .NET SDK's await-able functions?

Thank you very much!

Catalin

Re: Cancellation Token - Awaitable functions .NET SDK

Øystein_Kolsrud — Sun, 05 Jul 2020 12:01:00 GMT

There's no built in support for this I'm afraid, but you could write a function like this (sorry for the C#, I'm not too fluent in VB):

private static async Task<T> Cancellable<T>(Task<T> task, CancellationToken token) { var cancelTask = Task.Delay(TimeSpan.MaxValue, token); await Task.WhenAny(task, cancelTask); if (cancelTask.IsCanceled) throw new TaskCanceledException(task); return await task; }

Then with that function you should be able to write your code like this:

var tcs = new CancellationTokenSource(TimeSpan.FromSeconds(100)); var token = tcs.Token; try { var fi = await Cancellable(app.GetFieldAsync(field_name), token); await Cancellable(fi.SelectAsync(value, true), token); } catch (TaskCanceledException e) { Console.WriteLine("Operation was cancelled: " + e.Message); }

But it sounds strange that you should see it stall there in the first place. Is it reproduceable? Or is it non-deterministic?

Re: Cancellation Token - Awaitable functions .NET SDK

catalin — Sun, 05 Jul 2020 19:18:04 GMT

Exactly this degree of randomness consistent with a non-deterministic behavior makes my hair turn white. It's a Windows service that runs a scheduled Quartz.NET job each morning.

This service runs under a specific domain user who is also a root admin in QS. Now, this job iterates over a list of values and apply each of the list's value as a QS selection on that specific field and exports the data behind a table object as an Excel file.

Now I may have a clue: sometimes there's someone else, another user, who logs in with the same username as the service.

Is it possible if one opens a QS session with the same username to mess up the running job?

I'm speculating it would mess up the outputs of either the exported Excel file or the user's selections in the QS GUI, but it would not hang the entire execution.

Anyhow, I will wrap your nice suggestion for a cancel-able function with a retry policy and I will come back with a feedback.

Thanks a lot, @Øystein_Kolsrud!

Catalin

Re: Cancellation Token - Awaitable functions .NET SDK

Øystein_Kolsrud — Sat, 11 Jul 2020 08:32:42 GMT

Another user could certainly affect the results of the selection if that user connects to the same engine session as your service. You should make sure to use a unique session for the service when you connect to the engine. Something like this:

using(var hub = location.Hub(Session.Random)) { ... }

But depending on your connection type and proxy settings, it could be that you get disconnected if you have the same user connecting from somewhere else.

Re: Cancellation Token - Awaitable functions .NET SDK

catalin — Thu, 10 Sep 2020 07:09:36 GMT

So actually the Hub is the big daddy for the app object too?

Is this:

using (var app = location.App(appIdentifier, session: Session.Random)) { ... }

equivalent to calling the hub and then get the app? Means that this calls the hub anyway in the background, right?

Thanks alot!

Re: Cancellation Token - Awaitable functions .NET SDK

Øystein_Kolsrud — Thu, 10 Sep 2020 07:27:34 GMT

Yes, that is correct. The location.App is basically just calling location.Hub followed by hub.OpenApp.