FigureWidget state desynchronization with multiple concurrent Jupyter clients

Direct Answers

Does FigureWidget deduplicate retried updates? No. FigureWidget relies entirely on the ipywidgets comm layer, which provides at-least-once delivery without ordering guarantees or message IDs. Retried WebSocket messages are applied independently by each connected client, so duplicate payloads can produce divergent figure state.

How can developers detect state divergence? Attach an observe callback on the FigureWidget's _view_name or _model_id traits and compare the state dictionary across clients via a kernel-side registry. A simpler approach: periodically hash fig.to_json() on each client and report the hash to a shared kernel dictionary keyed by comm.comm_id.

What configuration enforces exactly-once semantics? None. Neither Plotly nor ipywidgets exposes a setting for exactly-once delivery. The Jupyter protocol (5.x) lacks acknowledgments, deduplication fields, or version vectors.

Why This Happens

The comm layer batches local trait changes via _hold_trait_notifications() but does not suppress duplicates originating from network retries or client reconnections. Each subscriber independently applies property changes; there is no server-side consensus. Plotly.js may also render optimistic updates before server acknowledgment, creating temporary visual divergence even when kernel state is consistent.

Practical Mitigation

Implement a kernel-side singleton manager that assigns monotonically increasing sequence numbers to every state mutation:

1. Wrap all FigureWidget updates in a manager method that increments a counter and attaches the sequence number to the comm payload.
2. On each client, store the highest-applied sequence number in a closure or widget trait.
3. In the client's on_msg handler, ignore any update whose sequence number ≤ last-applied value (idempotent apply).

This pattern works because the kernel is the single source of truth; clients merely replay an ordered log.

Verification Steps

Open two browser tabs connected to the same kernel. Create a FigureWidget and rapidly update a trace property (e.g., fig.data[0].y = new_data) from the kernel while simulating latency:

tc qdisc add dev lo root netem delay 100ms 20ms loss 5%

Observe whether both tabs render identical final state. Instrument the kernel-side comm.on_msg handler to log payload hashes; disconnect/reconnect one client to force retries and check for duplicate payloads.

One Diagnostic Detail Needed

Which Jupyter front-end are you using (JupyterLab, classic Notebook, Jupyter Server, or a custom deployment)? Reconnection logic and WebSocket implementation differ enough to change the frequency and pattern of duplicate messages, which affects whether the sequence-number mitigation is necessary or if simpler batching suffices.