Better handle fetching builds

Previously, an agent could end up fetching builds from the coordinator, but
not receiving the response, say because of a network issue or timeout. When it
retries, it would fetch even more builds, and there would be some allocated to
it, but that it doesn't know about.

These changes attempt to make fetching builds more idempotent, rather than
returning the new allocated builds, it returns all the builds, and rather than
requesting a number of new builds, it's the total number of allocated builds
that is specified.

1 files changed, 3 insertions, 0 deletions

diff --git a/guix-build-coordinator/agent-messaging/http/server.scm b/guix-build-coordinator/agent-messaging/http/server.scm
index 3c83e4c..8546b70 100644
--- a/guix-build-coordinator/agent-messaging/http/server.scm
+++ b/guix-build-coordinator/agent-messaging/http/server.scm
@@ -288,10 +288,13 @@ port. Also, the port used can be changed by passing the --port option.\n"
       (('POST "agent" uuid "fetch-builds")
        (if (authenticated? uuid request)
            (let* ((json-body (json-string->scm (utf8->string body)))
+                  ;; count is deprecated, use target_count instead
                   (count (assoc-ref json-body "count"))
+                  (target-count (assoc-ref json-body "target_count"))
                   (systems (assoc-ref json-body "systems"))
                   (builds (fetch-builds build-coordinator uuid
                                         (vector->list systems)
+                                        target-count
                                         count)))
              (render-json
               `((builds . ,(list->vector builds)))))