diff options
| author | Boris Kolpackov <boris@codesynthesis.com> | 2024-04-22 11:57:51 +0200 |
|---|---|---|
| committer | Francois Kritzinger <francois@codesynthesis.com> | 2024-06-05 09:12:46 +0200 |
| commit | f322e1f466c722850aa2ca2204c5abcf27bbd943 (patch) | |
| tree | 4c8ba03bb10e995a493e0c8db1bfa59e703cd0b2 /mod/tenant-service.hxx | |
| parent | 1ee750a80e9b7d8541e5957408c1aea87ee352bf (diff) | |
Specify new GitHub notification semantics
Diffstat (limited to 'mod/tenant-service.hxx')
| -rw-r--r-- | mod/tenant-service.hxx | 22 |
1 files changed, 12 insertions, 10 deletions
diff --git a/mod/tenant-service.hxx b/mod/tenant-service.hxx index 9a47459..3f1896b 100644 --- a/mod/tenant-service.hxx +++ b/mod/tenant-service.hxx @@ -53,16 +53,18 @@ namespace brep // While the implementation tries to make sure the notifications arrive in // 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 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. + // queued->building). As result, it is unlikely but possible to observe the + // state transition notifications in the wrong order, especially if + // processing notifications can take a long time. For example, while + // processing the queued notification, the building notification may arrive + // in a different thread. 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 |