Add a retry on ConnectionClosedException

[tchiotludo]

Hi,

Really often, we have this issues on our CI/CD process on Github actions:

* What went wrong:
Execution failed for task ':ui-ee:installNode'.
> org.siouan.frontendgradleplugin.domain.installer.RetryableResourceDownloadException: org.apache.hc.core5.http.ConnectionClosedException: Premature end of Content-Length delimited message body (expected: 44566491; received: 9958471)

Target environment

• OS: ubuntu-latest under Github Action
• JDK: 17 (temurin)
• Gradle: 8.3
• Plugins: id 'org.siouan.frontend-jdk11' version '8.0.0'

Settings in build.gradle file:

frontend {
    nodeVersion = '18.18.0'
    installScript = 'install --legacy-peer-deps'
    assembleScript = 'run build'
    checkScript = 'run test:unit'
}

[v1nc3n4]

Hi @tchiotludo,

Thank you for your feedback. To ease understanding and troubleshooting, there's a template that must be filled to report a bug. This is a mandatory step before considering your issue.

Anyway, starting from release 8.0.0, the plugin provides a configurable retry mechanism (see properties maxDownloadAttempts, retry... here). Let me know if this helps.

If you think there's really a bug, please provide information missing using the provided template. I'll be glad to help. Thank you! BR

[tchiotludo]

Hey @v1nc3n4, Thanks for the prompt response, sorry for the lack of template, since it's was a feature request (and not a bug), I don't think about use it. I have updated the issue with the template. I was not aware of this change of latest version with retry on some http status, I'm not sure this one will work since there is not http status on this exception.

But I discovered this options maxDownloadAttempts that should do the job, I will try.

Thanks a lot for pointing this.

[v1nc3n4]

I think the retry mechanism should work in your case, because it deals with connectivity issues (and yours seems to be one) as well as some HTTP error response. If you want to be sure that the retry works as expected with this exception, just set maxDownloadAttempt to a number higher than 1, and enable verbose mode (see verboseModeEnabled property). You should see a message for each download attempt in Gradle log.

Let me know the result 😀.

[tchiotludo]

Done here :rocket:

The bad news is: if it work I wouldn't see any error, so I will forgot that issue (because it work) :sweat_smile:

[v1nc3n4]

😄 Enabling verbose mode is the only way to see the issue in the log file and one or more retry attempts. Verbosity applies to the plugin only, not to Gradle.

For example, here's what log should look like:

>gradlew installNode

> Task :installNode
[installNode] Removing install directory '<project-directory>\node'
[installNode] Downloading distribution at 'https://unknown.domain/v18.17.1/node-v18.17.1-win-x64.zip'
[installNode] Downloading resource at 'https://unknown.domain/v18.17.1/node-v18.17.1-win-x64.zip' (proxy: DIRECT)
[installNode] Attempt 1 of 3: java.net.UnknownHostException: unknown.domain
[installNode] Downloading resource at 'https://unknown.domain/v18.17.1/node-v18.17.1-win-x64.zip' (proxy: DIRECT)
[installNode] Attempt 2 of 3: java.net.UnknownHostException: unknown.domain
[installNode] Downloading resource at 'https://unknown.domain/v18.17.1/node-v18.17.1-win-x64.zip' (proxy: DIRECT)
[installNode] Attempt 3 of 3: java.net.UnknownHostException: unknown.domain

> Task :installNode FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':installNode'.
> org.siouan.frontendgradleplugin.domain.installer.RetryableResourceDownloadException: java.net.UnknownHostException: unknown.domain

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 15s
1 actionable task: 1 executed

[v1nc3n4]

As it appeared to be a problem of configuration, I close the issue now. Feel free to reopen it you think there's a bug with the plugin's retry feature.

[tchiotludo]

@v1nc3n4 I didn't notice the errors any more, thanks for your help. Just a suggestion, increase the default value to 3 for example, if I have the issues, I think other people could have.

[v1nc3n4]

That was discussed here when the feature was designed, and a value of 1 was chosen for backward compatibility and to minimize risk with existing configurations because implementation appeared significant. That may be changed in the future however. Thank you for your suggestion.