Offline sync

Crews often work where there is no signal: in trenches, chambers and rural routes. ruumica is built so that work recorded offline is never lost and always ends in the same result, however late it arrives and in whatever order. The field app that uses this is not complete yet (Feature status); the rules below already run on the server.

Every change is an op

Each change made in the field, such as a new node, a split span, a splice or an attached photo, is an op: a small, self-contained record of what was done, by whom, on which device and when. Ops are kept on the device until they have been delivered. A device never changes the project directly; it only proposes ops.

Every op carries:

• an id made on the device, so things created offline never collide with things created elsewhere;
• a clock value that combines the device’s time with a counter, so all ops of a project can be put into one agreed order.

One agreed order

The server applies a project’s ops in that agreed order, one project at a time. When an op arrives late, for example from a device that was offline for two days, the server does not just append it. It replays the project from its starting point with the late op in its proper place. The result is the same as if every op had arrived on time, and every device and the server end up with the same network.

Because of a replay, an op’s status can change after you first saw it. Only REJECTED is final.

What happens to an op

Status	What it means for your work
APPLIED	Done as recorded.
REBASED	Done, on the right part of a network that changed meanwhile. Typically someone split the span you worked on, and your splice or photo was moved to the correct new span. Nothing is lost.
PENDING	Waiting. Either something it refers to has not arrived yet (MISSING_REFERENCE), which sorts itself out, or the server holds it for a reason, such as a missing height (Hold reasons).
CONFLICT	It contradicts another change, for example two people recording the same handhole. It has no effect yet; its data is kept for the office to decide.
REJECTED	Refused for good, with a reason, such as a file that did not arrive intact.
MOOT	A decision on a conflict that no longer exists.

Files travel separately

Photos and OTDR files are uploaded on their own, directly into storage, in parts that can resume after an interruption. Each file is identified by its SHA-256 fingerprint. An op that uses a file waits (BLOB_UNVERIFIED) until the server has checked that the uploaded file matches its fingerprint. An OTDR file is also judged again on the server, and if that differs from what the device showed, the server’s verdict counts (TRACE_SUMMARY_MISMATCH).

Starting point and the office

Sync is turned on per project with asbuilt sync enable. The project as it is at that moment, including its stored traces, becomes the starting point every replay begins from. asbuilt sync pending shows the office what has been waiting too long.

Your organisation only

Every op is checked against the person who sent it. Ops from someone outside the project’s organisation, or with a disabled account, are refused (USER_NOT_IN_ORG, USER_DISABLED), and another organisation’s project cannot even be seen.

See also

• Offline sync codes
• Roles and access