RbVmomi deserialization fails on managed object type `ContentLibrary`

[agrare]

Describe the bug
Running a simple WaitForUpdates event catcher (watching latestPage from the eventManager) [ref] and observed an exception when a scheduled "Sync Library" task ran. When we caught this event an exception was raised by deserialization because it couldn't find the ContentLibrary type. Further investigation shows that there was a task with an entity of ManagedObjectReference:ContentLibrary clib-2895

To Reproduce
Steps to reproduce the behavior:

1. Synchronize a Content Library
2. vim.serviceContent.taskManager.recentTask.first.info
3. 💥

>> vim.serviceContent.taskManager.recentTask.first.info
Traceback (most recent call last):
       16: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `traverse_data'
       15: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `each'
       14: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:119:in `block in traverse_data'
       13: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:90:in `deserialize'
       12: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `traverse_data'
       11: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `each'
       10: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:124:in `block in traverse_data'
        9: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:90:in `deserialize'
        8: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `traverse_data'
        7: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:106:in `each'
        6: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:124:in `block in traverse_data'
        5: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/deserialization.rb:87:in `deserialize'
        4: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/type_loader.rb:65:in `get'
        3: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/type_loader.rb:65:in `synchronize'
        2: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/type_loader.rb:67:in `block in get'
        1: from /home/grare/adam/.gem/gems/rbvmomi-3.0.0/lib/rbvmomi/type_loader.rb:105:in `make_type'
RuntimeError (unknown VMODL type ContentLibrary)

Expected behavior
Given that ContentLibrary isn't a registered ManagedEntity in the Managed Object Types I expect this is one of those special types that has to be merged into the vmodl.db

Screenshots
The task in the vSphere client:

TaskInfo from the MOB:

Platform:

• OS: Debian Bullseye
• RbVmomi Version: 2.4.1 and 3.0.0
• Ruby Version ruby 2.7.2p137 (2020-10-01 revision 5445e04352

[jrgarcia]

Sorry, I haven't gotten to this yet. The content library APIs are not available from SOAP. That's why it isn't registered as a ManagedEntity. I'll see what I can do to have it go around this.

[agrare]

No problem @jrgarcia If you know how you'd like to handle it I can take a crack at fixing it.

I could see adding a "stub" definition to the vmodl.wsdl or more generally changing the deserializer to create an object of the base class type for that property if it can't find the class in the vmodl.

Differentiating between an actual error and a case like this would be tricky though, but I don't know how many other cases like this there might be (where an internal definition "leaks" out over the public API).

This is mostly just annoying for us because it causes our WaitForUpdatesEx loops to raise out and we have to start from version="" again.

[agrare]

Hey @jrgarcia! I see you're no longer with VMware, congrats on the new job! Best of luck.
Do you know if there is there a new maintainer of this gem?

[jrgarcia]

Thanks, @agrare! Unfortunately, I do not know who will be working on this going forward. I'll see if I can find an answer for you, but as I have no access to anything internal to VMware anymore, I'm not sure I'll be able to get an answer too quickly.