@juergbi note that this issue is marginally related to the scheduler changes you are presently making.
Since it will no longer make sense to query the summary file at startup time to guess what is downloadable or not (whether this is because of CAS, or because we enable artifact expiry on remotes), we cannot really predict in advance whether we need to push the artifact or not.
I think that this redundant pushing is however causing excessive load on the artifact servers presently (this is my guess, since @jjardon seems to be simply confirming that the bug is still present, even though we never said it was fixed, it must be a high priority for him).
Perhaps we need a minor extension to the _pushreceive.py protocol for now so that we can:
Ask the server "Do you have this artifact right now ?"
Avoid pushing it at push time if the artifact existed already
There was a fix for this in !276 (merged) and that even added a regression test. The issue in the freedesktop-sdk case may be that the same remote artifact server is configured twice, once pull-only (in project.conf) and once with push enabled (CI config) and BuildStream doesn't properly deduplicate this.
Perhaps we need a minor extension to the _pushreceive.py protocol for now so that we can:
Ask the server "Do you have this artifact right now ?"
Avoid pushing it at push time if the artifact existed already
We actually already have this as well, however, it seems to be buggy. I've noticed this while working on the no-summary-file branch. Let me open a separate MR for this.