Paket fails to restore dependencies, despite valid solution being feasible

[optical]

Description

Paket is failing to resolve my dependency graph, despite the fact that a valid combination of dependencies exist. A verbose level install log can be seen here

The final error message is

Paket failed with:
        There was a version conflict during package resolution.
  Resolved packages:
   - Floating.Package 3.1.3
   - GemBox.Spreadsheet 37.3.30.1189
   - Newtonsoft.Json 6.0.3
   - Pinned.Package 4.28.0
  Could not resolve package Pinned.Package:
   - Dependencies file requested package Pinned.Package: 4.28
   - Floating.Package 3.1.3 requested package Pinned.Package: >= 4.30

  Please try to relax some conditions.

Repro steps

To reproduce, download and extract my sample setup here (apologies for size, it includes klondike)

1. Execute "ronKlondike.bat"

2. While klondike is running, in a seperate window run the boot strapper, followed by "paket install"

Expected behavior

Paket should be able to resolve the graph. Version 3.1.2 of "Floating.Package" should be selected, along with 6.0.8 of Newtonsoft.

Actual behavior

Paket gets hung up when trying to resolve FloatingPackage 3.1.3, which depends on PinnedPackage 4.30 >=, but our solution depends on PinnedPackage=4.28 and Floatingpackage >= 3.1.2. Floatingpackage 3.1.2 can use PinnedPackage 4.28, but it wants Newtsonsoft 6.0.8, whereas the solution floats Newtsonft >= 6.0.3 (which is fine). For some reason Paket tries to bump FloatingPackage, realises it cannot be used, but gives up before going back to 3.1.2 and trying to resolve Newtonsoft.

It looks as if Paket reaches a give up point and stops trying to resolve the graph, despite it being possible. Removing Gembox from the dependencies file also succeeds, despite it not having any dependencies of its own.

Known workarounds

Using the max resolver strategy works, as well as pinning the FloatingPackage to 3.1.2. We cannot use the max strategy due to #2134. We're resorting to pinning it for now, but would like to understand why this happens

[forki]

ok investigating

[forki]

confirmed it's a bug

[forki]

interestingly this was already fixed in paket 4 beta

[optical]

Thanks, confirmed to be fixed in my application now.