diff options
Diffstat (limited to 'mod/tenant-service.hxx')
| -rw-r--r-- | mod/tenant-service.hxx | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/mod/tenant-service.hxx b/mod/tenant-service.hxx index 92d8747..2b76b2d 100644 --- a/mod/tenant-service.hxx +++ b/mod/tenant-service.hxx @@ -53,15 +53,15 @@ namespace brep // the correct order, this is currently done by imposing delays (some // natural, such as building->built, and some artificial, such as // queued->building). As result, it is unlikely but possible to be notified - // about the state transitions in the wrong order, especially if the - // notifications take a long time. To minimize the chance of this happening, - // the service implementation should strive to batch the queued state - // notifications (or which there could be hundreds) in a single request if - // at all possible. Also, if supported by the third-party API, it makes - // sense for the implementation to protect against overwriting later states - // with earlier. For example, if it's possible to place a condition on a - // notification, it makes sense to only set the state to queued if none of - // the later states (e.g., building) are already in effect. + // about the state transitions in the wrong order, especially if processing + // notifications can take a long time. To minimize the chance of this + // happening, the service implementation should strive to batch the queued + // state notifications (of which there could be hundreds) in a single + // request if at all possible. Also, if supported by the third-party API, it + // makes sense for the implementation to protect against overwriting later + // states with earlier. For example, if it's possible to place a condition + // on a notification, it makes sense to only set the state to queued if none + // of the later states (e.g., building) are already in effect. // // Note also that it's possible for the build to get deleted at any stage // without any further notifications. This can happen, for example, due to |