Scenario:
- Launch Vat A running a service in Daemon Kernel on VPS.
- Launch Vat B running in metamask browser Plugin Kernel on laptop.
- B sends messages 1, 2, 3 to A as part of its normal application-level startup process. In support of this, Plugin Kernel establishes a remote comms connection to Daemon Kernel.
- A resolves the result values for these messages, but oops we discover there's a bug in B that's doing something wrong.
- Make a change to B to hopefully fix the bug, rebuild B.
- Reload the browser plugin, relaunching B.
- B sends message 1, 2, 3 to A as before, establishing a new connection from Plugin Kernel to Daemon Kernel.
- Daemon Kernel ignores messages as the sequence numbers belong to messages it has already seen.
- B hangs.
The mismatch is that Daemon Kernel is running continuously whereas the when the browser plugin was reloaded it restarted Plugin Kernel which thus lost its ephemeral state, which included the sequence numbers for its prior open connection to Daemon Kernel. Plugin Kernel opens a new connection to Daemon Kernel. but Demon Kernel somehow believes this new connection is the same as the old connection and expects continuity of message sequence numbers, which does not happen. Hilarity ensues.
It's unclear to me if this was an unanticipated and therefore unsupported case, or if it's just a bug in the disconnect/reconnect logic.
Scenario:
The mismatch is that Daemon Kernel is running continuously whereas the when the browser plugin was reloaded it restarted Plugin Kernel which thus lost its ephemeral state, which included the sequence numbers for its prior open connection to Daemon Kernel. Plugin Kernel opens a new connection to Daemon Kernel. but Demon Kernel somehow believes this new connection is the same as the old connection and expects continuity of message sequence numbers, which does not happen. Hilarity ensues.
It's unclear to me if this was an unanticipated and therefore unsupported case, or if it's just a bug in the disconnect/reconnect logic.