It is unclear, whether or not operation resumes normally after this happens, i.e. whether or not the thrown exception will be reported back to the calling Coordinator.
Unhandled Exception: DistrEx.Plugin.ExecutionException: Exception of type 'DistrEx.Plugin.ExecutionException' was thrown.
Server stack trace:
at DistrEx.Plugin.Executor.ExecuteWrapped(MethodInfo func, ExecutorCallback callback, String argumentTypeName, String serializedArgument, Object[] arguments)
at DistrEx.Plugin.Executor.ExecuteTwoStep(ExecutorCallback callback, ExecutorCallback completedStep1, String assemblyQualifiedName, String methodName, String argumentTypeName, String serializedArgument)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
Exception rethrown at [0]:
at System.Reactive.PlatformServices.DefaultExceptionServices.Rethrow(Exception exception)
at System.Reactive.Stubs.<.cctor>b__1(Exception ex)
at System.Reactive.AnonymousSafeObserver`1.OnError(Exception error)
at System.Reactive.Linq.Observαble.Where`1._.OnError(Exception error)
at System.Reactive.Observer`1.OnError(Exception error)
at System.Reactive.Subjects.Subject`1.OnError(Exception error)
at System.Reactive.Linq.Observαble.AsObservable`1._.OnError(Exception error)
at System.Reactive.AutoDetachObserver`1.OnErrorCore(Exception exception)
at System.Reactive.ObserverBase`1.OnError(Exception error)
at System.Reactive.Subjects.Subject`1.OnError(Exception error)
at System.Reactive.Linq.Observαble.AsObservable`1._.OnError(Exception error)
at System.Reactive.AutoDetachObserver`1.OnErrorCore(Exception exception)
at System.Reactive.ObserverBase`1.OnError(Exception error)
at System.Reactive.AutoDetachObserver`1.OnErrorCore(Exception exception)
at System.Reactive.ObserverBase`1.Fail(Exception error)
at System.Reactive.ObservableBase`1.ScheduledSubscribe(IScheduler _, AutoDetachObserver`1 autoDetachObserver)
at System.Reactive.Concurrency.ScheduledItem`2.InvokeCore()
at System.Reactive.Concurrency.CurrentThreadScheduler.Trampoline.Run(SchedulerQueue`1 queue)
at System.Reactive.Concurrency.CurrentThreadScheduler.Schedule[TState](TState state, TimeSpan dueTime, Func`3 action)
at System.Reactive.Concurrency.LocalScheduler.Schedule[TState](TState state, Func`3 action)
at System.Reactive.ObservableBase`1.Subscribe(IObserver`1 observer)
at System.ObservableExtensions.SubscribeSafe[T](IObservable`1 source, IObserver`1 observer)
at System.Reactive.Concurrency.Synchronization.<>c__DisplayClass2`1.<>c__DisplayClass4.<SubscribeOn>b__1()
at System.Reactive.Concurrency.Scheduler.Invoke(IScheduler scheduler, Action action)
at System.Reactive.Concurrency.DefaultScheduler.<>c__DisplayClass1`1.<Schedule>b__0(Object _)
at System.Reactive.Concurrency.DefaultConcurrencyAbstractionLayer.<>c__DisplayClass1.<QueueUserWorkItem>b__0(Object _)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Objectstate)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
In the
DistrEx.Plugin.Executorall exception types are handled. Some exceptions are intentionally rethrown.This is the point where the just-in-time debugger from Visual Studio attaches, if you run the
DistrEx.Worker.Hostfrom the VS debugger.N.B.: The JIT debugger seems to attach at the border of the plugin appdomain, when an exception is to be thrown to a caller that resides in another (in this case the app's default) AppDomain.
Thus, even though all exception types are handled, the managed code runtime still causes this error.
This needs to be fixed.
It is unclear, whether or not operation resumes normally after this happens, i.e. whether or not the thrown exception will be reported back to the calling Coordinator.
console log: