Chromiumos-sdk builders uploads the host packages early so that Goma can pick new tookchain packages earlier. However, it also updates make.conf.amd64-host config file before SDKTest stage. SDKTest stage takes several hours to run.

For instance, the SDK builder commits show 5 hour difference between modification of FULL_BINHOST and SDK_LATEST_VERSION. 

commit 5eaf6899d02e14aa2a45fe13b8b936de56aadfc1
Author: chrome-bot <chrome-bot@chromium.org>
Date:   Mon Jan 1 20:38:01 2018 -0800

    make.conf.amd64-host: updating FULL_BINHOST
    
    Change-Id: I22aa0777295f404864baf3dc1889fbdcca70c0ba

commit 18edcc8fc80ac6b2c78100f9a3e2e8c989832e81
Author: chrome-bot <chrome-bot@chromium.org>
Date:   Tue Jan 2 01:27:12 2018 -0800

    sdk_version.conf: updating TC_PATH, SDK_LATEST_VERSION
    
    Change-Id: I23e46ad74e7f54f05ec8b8ff955c5dcbdb5633ab

As a consequence of updating the make.conf.amd64-host file early, other builders pick any updates to host packages before the SDK builder can finish and update the chroot version.
If the SDK builder passes later (common case) and the packages are good, there is no problem.

However, if there is something bad with an upreved host package and SDKTest stage fails, any invocation of update_chroot will pull in the new (bad) host package. Reverting the SDK/host's config files will fix the builders but any developer chroot will still contain the bad package till the bad package gets another uprev.

If a toolchain package is bad, the number of bad host packages that may get pulled in might be fairly large. And it may happen that the only way to fix the chroot is to recreate the SDK causing a big grief.