include campaign ID in userspace messages, distinct from message ID #40
Description
Userspace messages should be sending three IDs in each message:
- a randomly-generated unique ID for each message; this is useful for logging purposes
- a "campaign" ID; this ID should generally be set by the Client/Orchestrator for each "campaign" it runs (for Clients, just set once). The Client should send this ID back in their request messages; Services should then make sure to include this campaign ID unchanged in the response message. This campaign ID should persist for the ENTIRE
- a "request" ID; this ID is meant to be generated by Clients right before sending a request message, and the Service reuses this ID when it sends a response message. After getting back the response message, the request ID is dropped from memory.
Currently, only the "request" ID is implemented, but it is erroneously called "message_id"; this is inconsistent with the message_id property we use for Event Messages and Lifecycle Messages, which are randomly-generated unique IDs.
further notes
- Lifecycle messages are not associated with campaigns, so do not need to include campaign IDs or request IDs
- Since event messages are generated by the Service, a campaign ID cannot reasonably be associated with them. For events not targeting a specific campaign/workflow/etc., this shouldn't matter. For targeted events, it would make sense for Service logic to start up a job in a request/reply/command message pattern (returning a job ID), and then include the job ID as part of its event response.
@marshallmcdonnell two things about this:
- these IDs, particularly the campaign ID, are necessary for the campaign orchestrator to function
- this will be targeted for the 0.9.0 release, as this will alter the message structure and I am proposing all of these IDs be required (so missing a field will fail message validation)