GitLab

@owanes idea of adding a growing list of UUIDs to the header so you could track back through the transaction history without everyone needing to maintain state. I think there's a nice way of doing this but it doesn't work in all scenarios.

1. The message header has a chain property
2. When an adapter builds a new message they have to populate the existing chain into the new message header
3. When the new message is sent the backbone adds the message type and UUID of the new message to the chain

This could be as a growing list

Implementation 1

{
  "chain": [
    {
      "message_type": "planning_configuration", 
      "uuid": "[uuid1]"
    },
    {
      "message_type": "mission_plan", 
      "uuid": "[uuid2]"
    }
  ]
}

.. the problem with this is that it gets big pretty quickly so you'd end up with every platform_status in the track in the chain since retasking the platform is triggered by the incoming status not by the incoming configuration

Implementation 2

{
  "chain": {
    "planning_configuration": "[uuid1]",
    "mission_plan": "[uuid2]"
  }
}

This has the advantage that it's much lighter and beyond the first few messages it doesn't grow.

The problem with both of these approaches is what triggers the outgoing message. In the case of a mission_plan the first message maybe be triggered by a planning_configuration but it's more likely it's triggered by a platform_status and all subsequent messages are triggered by platform_status

The platform_status is triggered by the platform so doesn't have a triggering incoming message at all.

This means it would be hard to get the planning_configuration uuid into the chain without some stateful-ness.

I think this may be worth doing for the approval process but the most important id in the chain is the planning_configuration in the mission_plan message so we need to solve how that gets populated.