Skip to main content
Several dispatchers and crews change the same incidents and units at once. Argus does not lock records while someone has a form open. Instead, each incident and each unit has a version number, and a change must say which version it was based on.

​
The rule

  1. Every incident and unit you read includes version.
  2. A change sends that version back.
  3. If the record has moved on, the change is refused with 409 CAD_CONFLICT and nothing is altered.
  4. A successful change returns the record with its new version. Use that for the next change.
If another request changed the unit first, its version is no longer 3:

​
Which version to send

Creating a record, attaching, converting or resolving a call, and booking on take no version.

​
What advances a version

More than the obvious edits. Plan for the version to change underneath you.
Assigning a unit or attaching a call advances the incident’s version. An edit form that has been open on a busy incident will often be stale by the time it is saved. Re-read the incident just before editing, and keep what the person typed if the save is refused.

​
Two kinds of 409

CAD changes run in serializable transactions. That is what stops two dispatchers assigning the same unit to different incidents, or a call being converted twice. The price is that one of two simultaneous requests can lose with CONFLICT even though neither sent a stale version. Treat both codes the same way.

​
What a client should do

1

Do not retry automatically

The state has changed. The action the person chose may no longer make sense: the unit may already be assigned, or the incident closed.
2

Read the record again

GET /api/cad/incidents/{id}, GET /api/cad/units, or GET /api/cad/me/unit for a crew.
3

Show the current state

Keep anything the person typed. Tell them the record changed.
4

Let them decide

If they still want the change, send it again with the new version.
Argus never replays a conflicting write itself. A success response always means that exact request was applied once.

​
Where versions are not used

The civilian, PNC, staff and administration endpoints have no version field. They guard against double changes in other ways: a warrant can only be executed while it is active, a marker can only be cleared once, and a second attempt returns a specific 409 such as WARRANT_NOT_ACTIVE or MARKER_NOT_ACTIVE. Simple field edits there are last-write-wins. Moderation uses an Idempotency-Key header instead, so that retrying a kick or ban can never send it twice.