From f632d0d3aaa0cf06bb660d5574b19a1120f43303 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Thu, 18 Apr 2024 11:16:08 +0200 Subject: Review --- mod/tenant-service.hxx | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'mod/tenant-service.hxx') diff --git a/mod/tenant-service.hxx b/mod/tenant-service.hxx index c9d0fa9..9a47459 100644 --- a/mod/tenant-service.hxx +++ b/mod/tenant-service.hxx @@ -54,15 +54,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 -- cgit v1.1