CloudQuery CLI 6.42.1 - Plugin Download Timeouts

CloudQuery published cli-v6.42.1 on September 2, 2026. The release has one entry, a bump of github.com/cloudquery/plugin-pb-go from v1.27.18 to v1.27.19. That module holds the code the CLI uses to download plugins, and the new version stops a silent server from hanging a plugin download indefinitely.

The full release notes and downloads are on the GitHub release page. It is a stable release, not a prerelease.

The notes list a single bug fix, #23333, merged as commit 5df8b4e. Renovate opened it. It touches three files: cli/go.mod, cli/go.sum, and the source plugin scaffold template scaffold/sourcetpl/templates/source/go.mod.tpl.

The compare view shows six commits. Under cli/, the only files that changed are go.mod, go.sum, and CHANGELOG.md. The other commits touch other parts of the monorepo. No flags, spec fields, or config keys changed. The Go directive in cli/go.mod stays at 1.26.5.

So the whole behavior change lives in the dependency. Newly scaffolded source plugins also start on v1.27.19 through the template.

The upstream fix is plugin-pb-go PR 684. It targets the managedplugin package, which downloads plugin archives for cloudquery sync and cloudquery plugin install. Before this version those requests went through http.DefaultClient. That client has no overall timeout. Its transport sets no response header timeout and no read deadline on the body. A server or proxy that accepted the connection and then went quiet could hold a sync until something in the network path dropped the TCP session.

The new client lives in managedplugin/download_client.go. Its settings:

  • Dial timeout of 10 seconds. The default transport used 30.
  • TLS handshake timeout of 10 seconds, same as before.
  • Response header timeout of 30 seconds. Previously there was none.
  • Idle read deadline of 30 seconds. Previously there was none.
  • Idle connection timeout of 30 seconds, down from 90.

The idle read deadline is the important one. A wrapper type, idleTimeoutConn, calls SetReadDeadline before every Read on the socket. It measures silence, not total transfer time. A slow download that keeps delivering bytes finishes. A download that receives nothing for 30 seconds fails.

The transport keeps http.ProxyFromEnvironment, so HTTPS_PROXY and NO_PROXY still apply.

When one of the new deadlines fires, a helper named downloadTimeoutError wraps the network timeout in a new sentinel, errDownloadStalled. The message reads download stalled: no data from <url>, with the query string stripped so signed tokens stay out of logs. isRetryableDownloadError classifies that sentinel as transient.

The existing retry settings then apply: RetryAttempts of 5, RetryWaitTime of 1 second, and MaxRetryWaitTime of 8 seconds. Every attempt truncates the local file and starts from byte zero. Both DownloadPluginFromHub and DownloadPluginFromGithub call the same downloadFile function, so Hub and GitHub sources both get the fix. The GitHub URL lookup in getURLLocation uses the new client too.

Caller cancellation is excluded on purpose. If the context is already canceled or past its deadline, the helper returns nil and the returned error still wraps the context error. The retry check refuses to retry context.Canceled and context.DeadlineExceeded. Upstream tests cover stalled headers, a stalled body, a slow but progressing transfer that must finish in one attempt, and both cancellation cases.

For operators the visible difference shows up in CI and scheduled sync jobs behind NAT gateways or egress proxies. A dead plugin download used to look like a job that ran until its outer timeout killed it. On 6.42.1 the same fault turns into a few retries and then a sync error that contains download stalled. You can alert on that.

The fix is narrow, and it has edges:

  • There is still no total deadline per download. The idle deadline only catches silence. A link that trickles a few bytes every 20 seconds never trips it.
  • The 30 second response header timeout applies to every attempt. A caching proxy that pulls the whole archive upstream before it sends headers can exceed that on a cold cache for a large plugin. If you run that kind of proxy, watch the first sync after a plugin version bump.
  • Plugin downloads now use HTTP/1.1. The new transport sets a custom DialContext and does not set ForceAttemptHTTP2. Go net/http turns off HTTP/2 for that combination. For one large archive per request, the practical cost is small.
  • The timeouts are package variables in plugin-pb-go. This release adds no CLI flag or config key to tune them.

If your syncs have never hung on a download, this release changes nothing you will notice. If they have, it is worth pulling. The 6.42.1 release notes are one line long, but that line changes how every plugin download behaves on a bad network.