diff options
| author | Karen Arutyunov <karen@codesynthesis.com> | 2025-02-14 14:08:04 +0200 |
|---|---|---|
| committer | Karen Arutyunov <karen@codesynthesis.com> | 2025-02-17 21:31:24 +0200 |
| commit | 62a6bd8d6bb576edf76c42db8ffb73fcb0f87fb7 (patch) | |
| tree | 867897ce90d2b7fe1d62a6c93feb44f4b69d5d1d /libbrep/package.hxx | |
| parent | 1795263201cc930c349add08aac8cc268796d773 (diff) | |
Automatically increase build queued timeout for big number of builds in 'queued' notifications
Note that this commit changes the semantics of the tenant::queued_timestamp
member. Previously it was set to the time when the build objects are turned
into the queued state. Now it is set to the time when the queued notification
for them is assumed to be delivered to the third party service.
Diffstat (limited to 'libbrep/package.hxx')
| -rw-r--r-- | libbrep/package.hxx | 17 |
1 files changed, 12 insertions, 5 deletions
diff --git a/libbrep/package.hxx b/libbrep/package.hxx index 2714d10..51af338 100644 --- a/libbrep/package.hxx +++ b/libbrep/package.hxx @@ -282,11 +282,18 @@ namespace brep // for it. It feels like there is no easy way to reliably fix that. // Instead, we just decrease the probability of such a notifications // sequence failure by delaying builds of the freshly queued packages for - // some time. Specifically, whenever the `queued` notification is ought - // to be sent (normally out of the database transaction, since it likely - // sends an HTTP request, etc) the tenant's queued_timestamp member is set - // to the current time. During the configured time interval since that - // time point the build tasks may not be issued for the tenant's packages. + // some time. Specifically, whenever the `queued` notification, + // potentially for multiple builds, is ought to be sent (normally out of + // the database transaction, since it likely sends one or more HTTP + // requests, etc) the tenant's queued_timestamp member is set to the time + // point when we assume this notification will finally be delivered to the + // service. This timestamp is calculated as the sum of the current time + // and some time interval, proportional to the number of the queued builds + // we need to notify the third party service about. Until this time point + // is reached, the build tasks may not be issued for the tenant's + // packages. The thinking here is that the bigger the number of builds we + // need to notify about, the longer it normally takes to deliver this + // notification. // // Also note that while there are similar potential races for other // notification sequences, their probability is rather low due to the |