Socket timeout when publishing via Portal OSSRH Staging API

[mmoayyed]

Thank you very much for this plugin.

Setup

I am using the following Gradle version:

------------------------------------------------------------
Gradle 9.0.0-rc-3
------------------------------------------------------------

Build time:    2025-07-17 12:48:00 UTC
Revision:      2db9560bb68c367a265b10516c856c840f9bed8d

Kotlin:        2.2.0
Groovy:        4.0.27
Ant:           Apache Ant(TM) version 1.10.15 compiled on August 25 2024
Launcher JVM:  21.0.8 (Azul Systems, Inc. 21.0.8+9-LTS)
Daemon JVM:    /Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home (no JDK specified, using current Java home)
OS:            Mac OS X 15.5 aarch64

...and using version 2.0.0 of the plugin here:

apply plugin: "io.github.gradle-nexus.publish-plugin"


nexusPublishing {
    packageGroup = "org.apereo"
    repositories {
        sonatype {
            username = "${repositoryUsername}"
            password = "${repositoryPassword}"
            nexusUrl.set(uri("${releaseRepositoryUrl}"))
            snapshotRepositoryUrl.set(uri("${snapshotsRepositoryUrl}"))
        }
    }

    clientTimeout = java.time.Duration.ofSeconds(120)
    connectTimeout = java.time.Duration.ofSeconds(120)
    transitionCheckOptions {
        maxRetries.set(100)
        delayBetween.set(java.time.Duration.ofSeconds(60))
    }
}

The URLs are defined as such:

releaseRepositoryUrl=https://ossrh-staging-api.central.sonatype.com/service/local/
snapshotsRepositoryUrl=https://central.sonatype.com/repository/maven-snapshots/

Problem

I am running the following task:

    ./gradlew publishToSonatype closeAndReleaseStagingRepository \
      --no-build-cache --no-daemon --no-parallel --no-watch-fs --no-configuration-cache \
      -DskipAot=true -DpublishReleases=true \
      -DrepositoryUsername="..." -DrepositoryPassword="..." \
      -Dorg.gradle.internal.http.socketTimeout=640000 \
      -Dorg.gradle.internal.http.connectionTimeout=640000 \
      -Dorg.gradle.internal.publish.checksums.insecure=true \
      -Dorg.gradle.internal.network.retry.max.attempts=5 \
      -Dorg.gradle.internal.network.retry.initial.backOff=5000

...this results in the following error:

* What went wrong:
Execution failed for task ':closeSonatypeStagingRepository'.
> java.net.SocketTimeoutException: timeout

Full error: https://pastebin.com/6eprimEp

This is a project that has a large number of subprojects. Is there a different timeout that one can or should set?

Note: token is valid and the publishing process has worked without an issue using the legacy service. This is now surfaced up when using the Portal OSSRH Staging API.

[szpak]

This plugin uses the other network client library than the Gradle itself. You can configure its timeout as follows:
https://github.com/gradle-nexus/publish-plugin?tab=readme-ov-file#http-timeouts

btw, from this line:

io.github.gradlenexus.publishplugin.shadow.okhttp3.internal.http2.Http2ExchangeCodec.readResponseHeaders(Http2ExchangeCodec.java:136)

I suspect read timeout (here "clientTimeout") should be increased.

Btw, is it a persistent behavior, it happened just once? Maybe OSSRH Nexus had "hard time" just once then?

[mmoayyed]

I did setup the following:

    clientTimeout = java.time.Duration.ofSeconds(120)
    connectTimeout = java.time.Duration.ofSeconds(120)

...and went as high as 20 minutes (for both even!); it is completely persistent and the timeout shows every time. I did reach out to sonatype support, and so far they seem clueless. Their last answer was:

You have appear to be publishing via the OSSRH Staging API Service (a compatibility service that translates a subset of the Nexus 2 APIs to the Portal API). In order for your deployments to appear in the Central Publisher Portal, you will need to add calls to manual endpoints to your build if you are using a "Maven-like" API (e.g. Gradle's default maven-publish plugin). The documentation linked previously should provide more information, but please let us know if you encounter any issues.

Which is weird because they explicitly in the documentation state that manual calls for this plugin should not be required.

Nonetheless, I tried going the manual route.

• I have modified the CI process to solely upload artifacts to https://ossrh-staging-api.central.sonatype.com/; this process creates and initializes a staging repository.
• Next, I tried sending a request to /manual/search/repositories?state=open to get the repository and its
  key.
• Next, I tried sending a request to /manual/upload/repository/${repositoryKey}?publishing_type=user_managed to upload this to the publisher portal.

The last step shows after a few minutes:

< HTTP/2 400
< date: Sun, 20 Jul 2025 04:14:16 GMT
< content-type: application/json
< content-length: 60
<
* Connection #0 to host [ossrh-staging-api.central.sonatype.com](http://ossrh-staging-api.central.sonatype.com/) left intact
{"error":"Failed to process request: Upload request failed"}

So the automatic process does not work and times out, and the manual API calls do not work. (I have tried this at least 3 times)

I am now going to try to create a bundle file as a zip file and upload that manually.

[szpak]

Which is weird because they explicitly in the documentation state that manual calls for this plugin should not be required.

As I understand it, if you are using the same IP in the subsequent upload/close command, it should be not needed.

Btw, do you see in the Nexus UI that the staging repository is effectively closed even after timeout passed (e.g. after one hour or so)? If not, what is the reason of failure?

[szpak]

Btw, do you see in the Nexus UI that the staging repository is effectively closed even after timeout passed (e.g. after one hour or so)? If not, what is the reason of failure?

Btw2, it's strange anyhow as "close" command just triggers closing and should return once it is acked on the server side. We latercheck state in the loop to notice, once it is effectively closed. However, here (from the stacktrace), calling close causes timeout which might suggests that they are processing the command itself too long - maybe in the "compatibility layer" - maybe due to the number of subprojects?
I would emphasis it in the further communication with their support, as it is not an error, but a timeout.

Btw3, is there chance that your CI uploading artifacts for different subprojects (effectively) using different IPs?

[mmoayyed]

Btw, do you see in the Nexus UI that the staging repository is effectively closed even after timeout passed?

No, nothing ever shows up in the portal.

maybe in the "compatibility layer" - maybe due to the number of subprojects?

I thought about this as well, but so far in my attempts, uploading a zip file using the "create a bundle and upload it" approach works OK, and with just as many modules.

I would emphasis it in the further communication with their support, as it is not an error, but a timeout.

I have tried this many many times; support is 100% either clueless, or responses are AI generated. I gave up. Responses are completely helpless and seem to ignore all evidence, notes and explanations.

Btw3, is there chance that your CI uploading artifacts for different subprojects (effectively) using different IPs?

No. I am mainly doing this locally for now. IP is always the same.

For now, it appears that I have some measure of success if I manually upload a zip bundle. This is also a VERY VERY finicky and error-prone process with super cryptic error messages. After wasting many hours, it turns out that the process does not support fat JARs (like a Spring Boot bootified JAR) and this spits out an error message that no human or deity can reasonably understand. (The legacy service had no problem with this)

I have worked around this for the time being, and I can now at least get the bundle validated and hopefully get it released. (We have 300+ subprojects here).

Thank you again for your time and attention here; if anything, I think this entire ordeal should make a good case for why the bridge API should not be readily trusted, and direct integration with the publisher APIs should be somewhat more smooth.

[szpak]

Thanks you for your elaboration. I agree that "the bridge API" might have extra corner cases that are covered in the documentation :-/.