Request Tracking

[ricejasonf]

For applications, the typical use case is such that the user makes a request (upstream message) and expects to know its status at any given moment. For access points that don't opt out of this, an additional store should be created that tracks requests by the message's UID. It's also possible to just use a single store to track all possible requests. It depends on how much we want to rely on the uniqueness of the locally generated UID.

This request tracking store should contain a variant that will likely have the following possible states:

• unresolved (pending)
• success
• error
• validation_fail (would contain a special object with messages)

Note that if the local state changes and would emit a downstream message, the request should be marked as resolved.

Note that there needs to be a way to know when to delete the tracking object from the store.

Note that the need for request tracking only applies to Create, Read and Update actions.

[ricejasonf]

Stores now receive messages from other paths via nbdl::apply_foreign_action. Request tracking could probably be implemented as a single store if the validation_fail object was somehow agnostic of the type of object it validated. (or it was a nbdl::variant of all the types of entities' validation result objects)