Review

1 files changed, 9 insertions, 9 deletions

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