Disconnect Behaviour

A robot connects over an ordinary internet link, not a dedicated cable — it will disconnect, and every part of the platform’s behaviour during and after that is a deliberate decision, not an afterthought.

Jobs keep running

A running action or service call is not aborted by a disconnect — the bridge keeps it going. Feedback, progress and the result are delivered once the connection returns. Every job carries a job id, exchanged between bridge and cloud, that keeps both sides in sync about which job is which.

Job state and buffers live only in the bridge’s memory. If the bridge process itself restarts during a disconnection (crash, update), unqueued results are gone — and the cloud reports those jobs honestly as lost after reconnect, never as “still running.”

No queue for commands to an offline robot

A command sent to an offline robot is rejected immediately with a clear error code. There is no queue waiting for reconnect. Build your app’s UI around the built-in bridge_state datapoint (online/offline + latency) so a user sees the robot is unreachable before they try to act on it.

Datapoints: timestamps, buffering, backfill

Every datapoint value carries timestamp_ms — the moment the bridge captured it, never the moment your app received it. Your app computes staleness itself from that; don’t trust a client-side “just now.” Action feedback carries the same field.

Buffering is configurable per datapoint — whether the bridge buffers values during a disconnect, and how many. An unbuffered datapoint simply has a gap after reconnect; per configuration, that gap is either backfilled or dropped.

After reconnect: live first, backfill trickles in. Live telemetry, bridge_state, and job delivery take priority. Buffered history flows in afterward at a bounded rate and closes the gap retroactively — so a chart that was live during the outage doesn’t get held up by history filling in behind it.

Publishers: failsafe and exclusivity

Every publisher has a developer-defined timeout (ms) and a failsafe message. If no client publish arrives within that window — including because the connection dropped — the bridge itself publishes the failsafe onto the topic. Classic example: a cmd_vel publisher with a 300 ms timeout and a zero-twist failsafe, so a lost connection doesn’t leave a robot driving on its last command forever.

Each publisher also has a user quiet-timeout: how long a publisher must be silent before a different user is allowed to publish to it. Publishing implicitly holds the publisher exclusively — no separate session mechanism needed.

What this means for your app

• Read bridge_state before you show anything that implies the robot is reachable.
• Treat a job’s terminal state (lost included) as final — don’t assume a lost job might still complete.
• Compute age from timestamp_ms, not from receive time — the two diverge under real network conditions, and a value can look “just captured” on your client clock while actually being stale on the robot’s.