diff options
| author | Boris Kolpackov <boris@codesynthesis.com> | 2024-04-22 11:57:51 +0200 |
|---|---|---|
| committer | Francois Kritzinger <francois@codesynthesis.com> | 2024-10-15 09:05:28 +0200 |
| commit | 4e8eeae58e94ac17301c432d9de80760ef7593b3 (patch) | |
| tree | 6a9a1e3b09e73c63e610f67f10dd9061f74c0f41 /mod/tenant-service.hxx | |
| parent | f632d0d3aaa0cf06bb660d5574b19a1120f43303 (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 |