Overview

It is possible for multiple people to be making changes to a single operation on a wasabee server at the same time. The Wasabee-Server software is designed to limit conflicting edits, but there is always the risk that edits will "step on" each other, or otherwise cause problems. The best solution is good communication.

Who can make changes to an operation

The owner of the operation can make changes to the operation, even if no permissions are set. Anyone on a team with write permission to an operation can make changes to the operation. These two should be fairly clear. Ideally any team with write access to an operation should be limited to just those who expressly need the access. Those with write access should communicate when they are making changes.

In addition to the operation owner and those on teams with write permissions, there are a limited number of cases where other agents can edit an operation. These are:

• Agents can change the status of markers and links which are assigned to them (mark the task as completed, reject the assignment, acknowledge the assignment)
• Agents can enter in key counts for anchor portals (those with incoming/outgoing links) and portals with "Get Key" markers.

While unlikely to conflict with other changes, these are technically "changes" to the operation data. These operations are atomic and thus unlikely to be accidentally overwritten by incorrect merges.

What the Wasabee-Server does to reduce problems from conflicts

Each time a change is made to the operation data on the server (e.g. when the operator updates the operation on the server, or when an agent marks a task as completed) an internal edit ID is updated. When Wasabee-IITC sends an update to Wasabee-Server, the client includes the last edit ID in the update. If the server's version doesn't match the client's version, the server responds with, "your version doesn't match what I have." This informs the Wasabee-IITC to download the most recent data from the server and try to merge the two together (starting at version 0.19). This is called "rebase" in Wasabee-IITC since it bases the edits on a newer version of the operation data from the server.

Conflict/Resolution example

This is a trivial case, but it shows the logic

1. Agent Joe (using Wasabee-IITC) downloads operation data version 23 from the server
2. Agent Joe makes some changes to the data
3. Agent Joe sends the changed data to Wasabee-Server, saying "this is based on 23"
4. Wasabee-Server responds "23 is the most recent version I have, so this is good. I've made the changes, it is now version 24." The server announces to all team members, "please update to 24"
5. Agent Kim (using Wasabee-Mobile) marks a target as complete. The server accepts the change and announces to all team members, "please update to 25"
6. Agent Joe was offline while this announcement went out, but resumes working on the operation using Wasabee-IITC.
7. Agent Joe sends the changed data to Wasabee-Server, saying "this is based on 24"
8. Wasabee-Server responds, "no, you should be on 25."
9. Agent Joe's Wasabee-IITC downloads 25, and displays an dialog to Agent Joe asking how to resolve the conflict:

• Use local (discard any changes on the server)
• Use server (discard changes made locally)
• Rebase (attempt to apply local changes to version 25)

10. Agent Joe pushes the updated version of the op to the server (either based on 25, or saying, "just overwrite what is there")
11. Wasabee-Server applies the changes, and announces to all team members, "please update to 26."

Atomic vs. Non-Atomic edits

In systems where events can happen from multiple directions at once, "atomic" events are those that cannot be divided up into smaller parts. "Non-atomic" events are those that are divisible.

Some Wasabee operations are atomic, these include:

• Changing marker status from Wasabee-Mobile and Wasabee-WebUI (claiming a marker, acknowledging an assignment, rejecting an assignment, marking an assignment as completed)

In Wasabee-IITC these are non-atomic and require the entire operation to be uploaded

• Adding an agent to a team; removing an agent from a team
• Setting team options (v/rocks integration, etc)
• Adding or removing operations permissions
• Changing an operation's owner
• Changing a team's owner
• Sending a target
• Updating agent key counts
• All changes made in Wasabee-WebUI
• All changes made in Wasabee-Mobile

These actions always take place atomically, without the need to upload the operation to the server, and with a much lower possibility of conflicts arising.

All other operations are non-atomic and require the operation to be uploaded to the server. Marker status/assignment changes, in particular, need to be carefully considered when pushing changes from Wasabee-IITC to the server. It is generally safe (after version 0.20) to make changes to the operation, then download any updates from the server, then push the merged changes. If agents are marking assignments as completed, (and FCM isn't triggering automatic downloads), remembering to frequently download, as well as frequently upload changes is important.

Since all changes made using Wasabee-WebUI are atomic, it can be advantageous to use the WebUI in some circumstances.