On different streams, the following line
commitObject = operations.receive(objId, transport, None)
will either variously:
return a ‘Base’ object
silently fail to set units with warning and return a ‘Base’ object
Fatal error on attempting something more complicated
Before I expand on which stream/branch/commit is causing each, am I missing something fundamental about reading transport with the SpecklePy API?
Hey @jonathon! As always, thanks for bringing this up!
This seems weird as the units should never be a Base object, but a string. I guess this could be an error on the sending side too… Do you get it consistently from commits sent from a particular connector/sdk?
For the second one, this seems like a bug too. Just checked both C# and Python object models and RenderMaterial seems to expect an int always. Could I also ask what application originated this commits?
Pinging @izzylys and who may know more as she’s the wizard in python here, and @Jedd for Material wisdom!
Thanks, @AlanRynne. If you think it’s not something I’ve done wrong through being dim - I’ll start to work through what I am looking at and report back.
I have streams with co-mingled commits created from about 6 different apps while I’m running through conversion testing. I just need to pick my battles a bit.
heya! at a first glance, it seems like something wrong with the data you’re receiving so I’d be curious about where it’s coming from
units should be strings and if they’re not then naturally it’s not possible to set them. this does not throw an error but a warning so that you can at least try and receive the rest of the data
same thing with the render material diffuse attribute. as the error states, this should be an integer and this will indeed fail if you try to set it as another type because then you’d be creating an invalid render material. you’d get the same behaviour in the desktop connectors.
not sure what the fatal error is about though as I’ve never encountered that so you’d need to provide a bit more info. it looks like it’s coming from your application / wherever you’re running the code rather than specklepy
The fatal with the Revit material error is an outlier as other warnings are just that and they pass through and still return the commit object. So far this is the only one I’ve found to kill it (if not caught)
I have set up a new branch in a new stream and pushed the Revit house to it as a single commit.
Selecting an object in the web viewer and using that URL moving forward:
Leads to unexpected results in Grasshopper and in Python:
Where the specific line throwing the error
object = client.object.get(stream_id, object_id)
Having passed the sample URL https://speckle.xyz/streams/fd1d44405d/objects/8cef13a1faf0665b2b0e035f75986f33 into a StreamWrapper helper.
Stream and commit all public. That the grasshopper component sees something altogether different to the be UI is surprising, but I may be dim.
Regarding the python error, it looks like there’s a problem with your local db. This probably happened previously when receiving invalid objects which would have cancelled the receive operation partway through causing some but not all of the child objects to be stored in the db.
Could you please either clear your local cache from the Speckle Manager settings page or just delete the Objects.db at %APPDATA%\Speckle. From specklepy, you can also bypass the local cache and force receiving from the server transport by passing a MemoryTransport to operations.receive as the local_trasport - I do this sometimes for debugging or dev if I’m working on new connectors / models and prone to breaking something 
EDIT: just wanted to add that I’ve used the sample URL you provided and have received in py without problems 
You had me excited through breakfast, not gonna lie.
Sadly, removing the Objects.db and Data.db from ~/.config/speckle clearing cache with Manager and even a hard restart didn’t change the behaviour in either GH nor specklepy as if its being cached someplace else.
I’ll bypass the local as you suggest (not sure how that would be done in GH) and report back.
oh no, how odd 
are you on linux or mac? if linux, the objects db could also be at ~/.local/share/Speckle
let me know how the forced server receive goes! I’m also not sure how to do this in GH lol
there are receive / send components for specific transports but it doesn’t look like there’s a standalone server transport GH component. maybe @AlanRynne has an idea?
You can bypass the local cache by disabling the option in the right click menu on the sender, for the receiving side, there’s no way to deactivate it currently, but i’d be happy to add it to my list if it’s a useful addition when/while testing stuff!
Mac. The GH connector was lifted from @AlanRynne 's private stash. 
Nevertheless,
memoryTestObject = operations.receive(object_id, transport, MemoryTransport())
Appears to succeed!! 
SpeckleWarning: Invalid units: expected type str but received <class 'NoneType'> (None). Skipping - no units will be set.
warn(
Base(id: 10ccf0ccdb46f79a24400319a71685b5, speckle_type: Objects.BuiltElements.Wall:Objects.BuiltElements.Revit.RevitWall, totalChildrenCount: 3)
It definitely working enough for me to get through this next bit on the broken streams. (Seems to be a Revit thing but not exhaustively tested yet)
yay fantastic! I’m a bit confused as to where else the cache could be pulling from, but glad you got it working anyway 
will be interested to hear what you find as you dig into the weird streams 