Claus Ibsen created CAMEL-26914:
-----------------------------------
Summary: camel-jbang - outbound network calls: GitHub errors are
swallowed, fetches without timeouts, and a stalled response body hangs past the
timeout
Key: CAMEL-26914
URL: https://issues.apache.org/jira/browse/CAMEL-26914
Project: Camel
Issue Type: Bug
Components: camel-jbang
Reporter: Claus Ibsen
Fix For: 4.24.0
Found by an analysis of the Camel CLI on the night of 2026-11-12, with the
unpacked 4.24.0-SNAPSHOT camel-launcher on macOS. *(exp)* means reproduced by
experiment, *(read)* means traced in the code. Paths are relative to
{{dsl/camel-jbang/}}, and line numbers are from main at that time. Dependency
resolution of camel run is covered separately by CAMEL-26901.
h3. 1. GitHub and gist listings swallow non-200 responses (exp)
{{GitHubHelper}} (camel-jbang-run {{common/GitHubHelper.java}} around lines
157-188) and {{GistHelper}} (around lines 88-121) ignore the status code. With
a 404, or a 403/429 rate limit (60 requests an hour unauthenticated, and
{{GITHUB_TOKEN}} is not supported), {{camel init <url>}} writes nothing and
exits 0, and {{camel run <url>}} says "No routes found". They should report the
status (and the rate limit), exit non-zero, and send {{GITHUB_TOKEN}} when it
is set.
h3. 2. Fetches with no timeouts (read)
{{URL.openStream()}} with no connect or read timeout:
* components/camel-resourceresolver-github {{GitHubResource}} and
{{GistResource}}, used by camel run and camel init
* {{PipeProvider}} of camel bind (around line 112)
{{exists()}} swallows every error as "does not exist". The core
{{HttpResource}} got timeouts in CAMEL-24756; these did not.
h3. 3. The JDK HttpRequest.timeout() does not bound the response body (exp)
A server that sends the headers and then stalls hangs
{{send(BodyHandlers.ofString())}} past the timeout (still blocked after 18s
with a 3s timeout). Affected:
* {{GitHubHelper}}:158, {{GistHelper}}:89, {{ExampleHelper}}:553,
{{VersionList}}:574, {{QuarkusHelper}}:348, ai {{DependencyLookup}}:72
* launcher {{ManifestFetcher}}:218 and {{InstallScriptFetcher}}:102
* {{LlmClient}} streaming: {{camel ask}} can hang mid-answer, there is no idle
timeout
Suggested fix: {{sendAsync}} plus {{get(timeout)}}, or a body handler with a
deadline.
h3. 4. camel self-update has no time limit and no output (read)
{{SelfUpdateCommand}} (around line 369) uses {{readAllBytes()}} plus an untimed
{{waitFor()}}, and install.sh runs {{curl}}/{{wget}} without a connect or max
time.
h3. 5. camel infra run --background loses the child's output (read)
{{InfraRun}} (around lines 173-186) starts the child with the default pipes and
returns. If Docker is down, the user only sees "Running in background".
h3. 6. camel debug reads stderr only after exit (read)
{{Debug.java}} (around lines 459, 565, 614) can block on a full stderr pipe,
and {{doReadLog}} spins at 100% CPU after EOF.
h3. 7. Vertex AI runs gcloud auth print-access-token on every LLM request (read)
{{LlmClient}} (around lines 1704-1748): each call costs about 1s, has no
timeout, and merges stderr into the token. The token should be cached until it
expires.
h3. 8. QuarkusHelper offline (read)
When the daily refresh fails, it throws instead of using the stale cache it has.
h3. 9. camel version list makes one sequential, uncached GET per unknown
version (read)
They run before the {{--lts}}/{{--patch}} filters, and misses are never cached.
h3. 10. GitHub example downloads (read)
The download of an example ({{camel run --example}}, and the TUI) is sequential
and skips failed files silently. The TUI {{OsvClient}} also fetches
vulnerability details one at a time.
h3. Came out clean
The Kubernetes plugin, the MCP server (no outbound HTTP), the HTTP and process
handling of the TUI, and the core {{HttpResource}}. No security issues that
need private triage were found.
h3. Suggested order
# 1 (silent failure)
# 2, 3, 4 (hangs)
# the rest
_Claude Code on behalf of Claus Ibsen (davsclaus)_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
