Rhino.Compute error depending on order of requests

I am currently experimenting with compute.rhino3d.appserver and rhino compute (compute.geometry).

The workflow is followed: VUE: upload geometry, request to compute.rhino3d.appserver -> compute.rhino3d.appserver: request to rhino compute -> rhino compute: calculate result, all on localhost.

The problem is that evaluating some of these files with rhino.compute work sometimes and sometimes they do not, depending on the order of execution. The file provided first works, the second and following ones leads to something similar to

[12:13:43 DBG] Using cached definition
[12:13:43 ERR] An exception occured while processing request
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Rhino.FileIO.DracoCompression.Compress(Mesh mesh, DracoCompressionOptions options)
   bei Script_Instance.RunScript(Mesh mesh, Object& base64Draco) in c:\Users\borstm\AppData\Local\Temp\i40otx04.0.cs:Zeile 62.
   bei Script_Instance.InvokeRunScript(IGH_Component owner, Object rhinoDocument, Int32 iteration, List`1 inputs, IGH_DataAccess DA) in c:\Users\borstm\AppData\Local\Temp\i40otx04.0.cs:Zeile 106.
   bei ScriptComponents.Component_AbstractScript.SolveInstance(IGH_DataAccess access)
[12:13:43 DBG] Skipping input tree... same input
[12:13:43 DBG] Warning in grasshopper component: "Txt" (3f13e936-e4d4-4af0-b814-ae6ce1c39708): Floating parameter Txt failed to collect data - [2020-12-01T12:13:43.4639377+01:00] "POST /grasshopper HTTP/1.1" 200 -

In between the successful exections I restarted rhino compute and the appserver.
Both of the files are just simple cube geometries, but the problem persists with more complex geometry; the first submitted file works, following ones will not. The definition of the geometry is not imported again, so it’s not an issue with rhino3dm either, the same data just get’s submitted again.

The definitionPathand the trees variable as used in https://github.com/mcneel/compute.rhino3d.appserver/blob/main/src/routes/solve.js#L136 are the same for different execution orders of the same file, so I don’t think that there is an issue with the compute.rhino3d.appserver. Maybe there is a problem with the cached definition?

I can provide the source code/grasshopper definition for replicating, as long as it’s not made publicly available.

I apologize if the problem turns out to be my own bug and not an issue with rhino.compute.

Martin :smiley:

Example files box.stl (1.3 KB) Cube_3d_printing_sample.stl (684 Bytes)

Hey @martinborst1, are you using the latest version of Compute? This looks like a bug we fixed recently that caused cached definitions to be recomputed without the new input values. This was an issue with Compute, not the AppServer, but you’d need to restart the AppServer too to clear its cache.

1 Like

Thank you!
I am now watching the compute.rhino3d repository in order to avoid missing out on relevant commits.

1 Like