Deserialization errors when updating the view after the first synchronization

[bourdaisj]

Description

When instantiating the LocalView with a vtkCameraOrientationWidget and updating the view afterwards, there are errors in JS console:

 JS Error => 2026-07-03 11:42:52.260 (   2.270s) [          8F87F4]    vtkDeserializer.cxx:88     ERR| vtkDeserializer (0x91e4d0): No state found at id=27
 JS Error => 2026-07-03 11:42:52.262 (   2.272s) [          8F87F4]vtkOpenGLRendererSerDes:184    ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed
 JS Error => 2026-07-03 11:42:52.263 (   2.273s) [          8F87F4]    vtkDeserializer.cxx:88     ERR| vtkDeserializer (0x91e4d0): No state found at id=54
 JS Error => 2026-07-03 11:42:52.264 (   2.274s) [          8F87F4]vtkOpenGLRendererSerDes:184    ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed
 JS Error => 2026-07-03 11:42:52.264 (   2.274s) [          8F87F4]vtkRendererCollectionSe:79     ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed
 JS Error => 2026-07-03 11:42:52.265 (   2.276s) [          8F87F4]vtkOpenGLRenderWindowSe:248    ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed
 JS Error => 2026-07-03 11:42:52.265 (   2.276s) [          8F87F4]vtkWebAssemblyOpenGLRen:163    ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed

Id's 27 and 54 reported above are the camera ids for the parent renderer and the camera widget renderer. This seems to be related to vtk-wasm unregistering the state of those ids, since cameras ids ends up in ignored ids in the "vtklocal.get.status" protocol.

Where does the issue originate?

Upstream Project (vtk.wasm JS bindings)

Version Information

"trame>3.13", "trame-vtklocal==1.0.1", "vtk==9.6.20260405.dev0"

Steps to Reproduce

Just run this script with uv, the dependencies are included in the shebang. After running, click the "update" button in the toolbar and you should see the errors.
repro.py

Relevant Log Output

JS Error => 2026-07-03 11:42:52.260 (   2.270s) [          8F87F4]    vtkDeserializer.cxx:88     ERR| vtkDeserializer (0x91e4d0): No state found at id=27
 JS Error => 2026-07-03 11:42:52.262 (   2.272s) [          8F87F4]vtkOpenGLRendererSerDes:184    ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed
 JS Error => 2026-07-03 11:42:52.263 (   2.273s) [          8F87F4]    vtkDeserializer.cxx:88     ERR| vtkDeserializer (0x91e4d0): No state found at id=54
 JS Error => 2026-07-03 11:42:52.264 (   2.274s) [          8F87F4]vtkOpenGLRendererSerDes:184    ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed
 JS Error => 2026-07-03 11:42:52.264 (   2.274s) [          8F87F4]vtkRendererCollectionSe:79     ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed
 JS Error => 2026-07-03 11:42:52.265 (   2.276s) [          8F87F4]vtkOpenGLRenderWindowSe:248    ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed
 JS Error => 2026-07-03 11:42:52.265 (   2.276s) [          8F87F4]vtkWebAssemblyOpenGLRen:163    ERR| vtkDeserializer (0x91e4d0): Superclass deserialization failed

[bourdaisj]

@jourdain @jspanchu Not sure about where the problem should be fixed.

[jspanchu]

Server is not pushing camera (push_camera = False is default in trame-vtklocal). Client sees that there is no state for the camera and complains. These errors are safe to ignore. The thing is when a state is missing it can genuinely be of concern. Here it’s not a concern.

[bourdaisj]

Understood. But still, this is reported as an error in the logs. So either this should not be logged as an error and we should downgrade to warning of info, either there is a logical bug that leads to trying to get camera state even though it does not exists

[jspanchu]

it's hard to determine what needs done here. the server should probably erase the camera from the renderer's state like {ActiveCamera: null} instead of sending {ActiveCamera: {Id: 27}}

[jourdain]

No the camera should still be linked on the server. And the client should not "unbind" its id:27.

Because of the server knowledge, can be used to query 27 on the client and/or sync it back up with the server.

This is indeed wrong.