Dynamo: package manager crashes when installing a package

[ksobon]

Dynamo 2.5 Revit 2021. Installing Monocle.

Sequence contains no matching element

at System.Linq.Enumerable.FirstTSource
at Dynamo.PackageManager.PackageManagerSearchElement.<>c.b__61_1(Tuple2 pair) at System.Linq.Enumerable.WhereSelectEnumerableIterator2.MoveNext()
at System.Linq.Enumerable.AnyTSource
at Dynamo.ViewModels.PackageManagerClientViewModel.ExecutePackageDownload(String name, PackageVersion version, String downloadPath)
at Dynamo.PackageManager.ViewModels.PackageManagerSearchElementViewModel.OnRequestDownload(PackageVersion version, Boolean downloadToCustomPath)
at MS.Internal.Commands.CommandHelpers.CriticalExecuteCommandSource(ICommandSource commandSource, Boolean userInitiated)
at System.Windows.Controls.Primitives.ButtonBase.OnClick()
at System.Windows.Controls.Button.OnClick()
at System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs e)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender, RoutedEventArgs args, RoutedEvent newEvent)
at System.Windows.UIElement.OnMouseUpThunk(Object sender, MouseButtonEventArgs e)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
at System.Windows.Input.InputManager.ProcessStagingArea()
at System.Windows.Input.InputManager.ProcessInput(InputEventArgs input)
at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

[mjkkirschner]

Hi @ksobon thanks for the report -
Do you have any special setup or is this just regular 2021 release?
Were you downloading the latest version of monocle?
Is it reproducible with Monocle?
Do you see this error with any other package?

[mjkkirschner]

@zeusongit @mmisol any insights here?

[mjkkirschner]

It strangely reminds me of this:
https://github.com/DynamoDS/Dynamo/pull/10561
but that crash would not have been introduced until 2.7 timeframe...

[mmisol]

Tried it on latest Dynamo (2.7.0.8834) and it did install although the MonocleViewExtension threw a NullReferenceException on Loaded, which does not seem related.

We'll probably have to try this with 2.5 as the code changed a lot on recent versions due to the refactors we did to improve latency.

[mmisol]

Taking a look at the code in 2.5 I have a theory for what could have happened.

Matching the stack trace to the code, I can see where this error originates here: https://github.com/DynamoDS/Dynamo/blob/RC2.5.0_master/src/DynamoPackages/PackageManagerSearchElement.cs#L182

That can only fail if the package version being installed depended on a version of some other package that could not be found. That sounds inconsistent but can be true for a brief amount of time due to cache.

If we take a look at where the pieces of information are obtained, we can see that the package version being installed is obtained from https://github.com/DynamoDS/Dynamo/blob/RC2.5.0_master/src/DynamoCoreWpf/ViewModels/PackageManager/PackageManagerClientViewModel.cs#L465 while the headers of all dependencies are obtained from https://github.com/DynamoDS/Dynamo/blob/RC2.5.0_master/src/DynamoCoreWpf/ViewModels/PackageManager/PackageManagerClientViewModel.cs#L509. Each call uses a different endpoint, while the first one uses /package/:engine/:name the second one uses /package/:id. We are currently caching the second endpoint but not the first one.

My theory is this problem is caused by /package/:engine/:name returning information more up-to-date than we have in the cache, and then when we call /package/:id we are hitting cache and not finding the most recent data. If this is the case, this will affect versions of Dynamo prior to 2.6, but the error should disappear after the cache refreshes, which happens every few minutes.

As a fix, we could use caching for the /package/:engine/:name route as well. That would provide consistent results as we would be using cache for all related calls.

[ksobon]

@mmisol your analysis of the report seems to be accurate. I got word from @johnpierson that he just posted the latest version of his package, so I quickly installed it. That's when the crash happened. If there was indeed a cached version of the package on my PC when that call was made, it could have been the cause here. I tried installing it again, few minutes later and it worked fine.

@mjkkirschner nah. This was just Monocle. I have a regular 2.5 in Revit 2021. I think @mmisol is onto something here.

[zeusongit]

Well we are updating the cache on every post/put action that has to do with packages. So, as soon as the new version gets uploaded, the cache should have it as well. But I did some digging and turns out that the cache gets updated only for the default engine, but since we are providing the engine name with /package/:engine/:name endpoint, it skips that part.

[mjkkirschner]

this should be fixed now, even in older versions of dynamo.