This message was deleted.

No, it’s currently not possible.

Well rather the opposite. I'd say that 95% of our devs have fiber connections, and the only issue that would hinder the scans from uploading is not being on the VPN, and retries won't help with that. So I think the retries are meaningless for us, and I would set them to 0 to reduce console clutter.

I saw the same behaviour. When it fails we don't want to retry because it's a VPN issue for sure.

@Fritjof Höst @CristianGM do you know why this manifests as a timeout in your case? We attempt to only retry on transient errors. For example, we don’t retry on “connection refused”. Is it intentional that your firewall or similar doesn’t reject the request when not on the VPN?

I'm not really into all of the networking stuff, but the url we use is

<http://gradle>.<somedomain>.net

, where the

<somedomain>

is not our own domain, but one that theoretically could be used on the internet. I wish I could help more, but I'm not sure what I would be looking for 🙂

If the uploading in background is set to true, it should prevent have this issue. no?

When the uploading happens in the background, there is still a very fast foreground request to essentially get a token from the server, and reserve a Build Scan slot. This could fail as well. But nonetheless, the background process may suffer from the same connection problems. The failure will just be absent from the main process, and will be in your

~/.gradle/build-scan-data/upload-failure.log

(in case of a Gradle build) see this doc

I see, thanks for the explanation. So, this will behave as a fire-and-forget of the scan. I understood that is what is intended for the OP 👀

there is still a very fast foreground request to essentially get a token from the server, and reserve a Build Scan slot

That would make the build slow anyway retrying @Cristian Garrido