hyperledger
Add ~thread decorator information to webhooks that don't have it
We have found that some webhook notifications to the controller (such as RFC 0160 Connections) do not have the ~thread decorator from the protocol being executed. This is at minimum useful and in some cases required for the controller to track requests across many protocol instances. For the initial message of a protocol, the ~thread decorator is (often) not present in the message and so the id for the message must be included in the webhook data (the id of the first message becomes the thid of the protocol instance). The id could always be added to all of the webhooks as well.
The task is to review all webhooks related to protocol messages and add the ~thread decorator or id (for first messages of a protocol only) to all webhooks.
Controller writers -- such as @ianco , @burdettadam , @dbluhm -- how crucial do you think this change is? Obvs we've not noted this previously, but it seems pretty important for a controller to know the context of a webhook received related to a running protocol instance.
If I'm not mistaken, we're currently using record IDs to correlate requests and webhooks, usually. However, it recently came to our attention that having more visibility and control of threading from the controller layer would better enable things like controller orchestrated "super-protocol" or "sub-protocol" flows. The included threading info would help ensure things are grouped and ordered in a coherent way for the recipient, especially when the recipient is behind a mediator or other networking scenarios where messages may arrive out of order.
