Android: fix HttpURLConnection leak in TalkModeVoiceResolver by Kaneki-x · Pull Request #43780 · openclaw/openclaw

Kaneki-x · 2026-03-12T07:09:20Z

Summary

TalkModeVoiceResolver.listVoices() opens an HttpURLConnection to the ElevenLabs API but never calls conn.disconnect(), and the response InputStream is never closed. Each call leaks a connection, which accumulates over repeated voice list fetches and can exhaust the connection pool.

Fix

Wrap the connection usage in try/finally { conn.disconnect() } to ensure the connection is released on all paths (success, HTTP error, parse error, exception).
Use stream.use { it.readBytes() } to close the InputStream after reading.

Test plan

Code review: verified conn.disconnect() runs on all exit paths (normal return, HTTP 4xx/5xx throw, JSON parse exception).
Verified stream.use {} closes both inputStream and errorStream paths.
Manual test: call voice list multiple times and confirm no connection leak in network profiler.

This PR was authored with AI assistance.

@steipete @obviyus Would appreciate a review when you have a chance.

Made with Cursor

greptile-apps · 2026-03-12T07:11:29Z

Greptile Summary

This PR fixes a real HttpURLConnection leak in TalkModeVoiceResolver.listVoices() by wrapping connection usage in try/finally { conn.disconnect() } and closing the response stream with stream.use { it.readBytes() }. The structural intent is correct, but there are two issues worth addressing before merging.

NPE risk on null errorStream: HttpURLConnection.getErrorStream() can return null when an error response has no body. The current code assigns this to stream and then calls stream.use { it.readBytes() } — since it is a platform type that resolves to null, readBytes() will throw NullPointerException. Fix: stream?.use { it.readBytes() } ?: byteArrayOf().
conn.disconnect() defeats connection pooling: On Android 4.4+, HttpURLConnection is backed by OkHttp. Closing the stream via stream.use {} already returns the connection to the pool. The unconditional conn.disconnect() in finally then tears it down, negating keep-alive benefits for repeated listVoices() calls.

Confidence Score: 3/5

Not safe to merge as-is — the null errorStream path introduces a NPE that can crash the app on any 4xx/5xx response with no body.
The fix addresses the original leak correctly, but introduces a crash path via null errorStream that needs a one-line fix before this is production-safe. The disconnect() concern is a performance issue, not a crash risk.
apps/android/app/src/main/java/ai/openclaw/app/voice/TalkModeVoiceResolver.kt — lines 89-90 (null errorStream NPE) and lines 104-106 (conn.disconnect() vs. connection reuse)

Prompt To Fix All With AI

This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/voice/TalkModeVoiceResolver.kt
Line: 89-90

Comment:
**Null `errorStream` causes NPE on error responses with no body**

`HttpURLConnection.getErrorStream()` returns `null` when the server returns a 4xx/5xx response with no body (per Android docs). On that path `stream` becomes `null`, and `stream.use { it.readBytes() }` will pass `null` as `it` and crash with a `NullPointerException` when `readBytes()` is called on it.

Use the safe-call operator and fall back to an empty array so the subsequent error message path still works cleanly:

```suggestion
        val stream = if (code >= 400) conn.errorStream else conn.inputStream
        val data = stream?.use { it.readBytes() } ?: byteArrayOf()
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/voice/TalkModeVoiceResolver.kt
Line: 104-106

Comment:
**`conn.disconnect()` defeats HTTP keep-alive / connection reuse**

On Android 4.4+ `HttpURLConnection` is backed by OkHttp. Simply closing the response stream (already done by `stream.use {}` above) returns the underlying TCP connection to the pool for keep-alive reuse. Calling `conn.disconnect()` unconditionally in `finally` then immediately tears that connection down, which negates the pooling benefit and adds latency for every subsequent call to `listVoices()`.

The `finally` block is still useful for the case where an exception is thrown before `stream` is ever opened (e.g. a connection timeout), but in the happy path it is counterproductive. Consider disconnecting only on error, or removing it entirely and relying on stream-close for cleanup:

```kotlin
} catch (e: Exception) {
    conn.disconnect()
    throw e
}
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 63e946e}

greptile-apps · 2026-03-12T07:11:32Z

apps/android/app/src/main/java/ai/openclaw/app/voice/TalkModeVoiceResolver.kt

+        val stream = if (code >= 400) conn.errorStream else conn.inputStream
+        val data = stream.use { it.readBytes() }


Null errorStream causes NPE on error responses with no body

HttpURLConnection.getErrorStream() returns null when the server returns a 4xx/5xx response with no body (per Android docs). On that path stream becomes null, and stream.use { it.readBytes() } will pass null as it and crash with a NullPointerException when readBytes() is called on it.

Use the safe-call operator and fall back to an empty array so the subsequent error message path still works cleanly:

Suggested change

val stream = if (code >= 400) conn.errorStream else conn.inputStream

val data = stream.use { it.readBytes() }

val stream = if (code >= 400) conn.errorStream else conn.inputStream

val data = stream?.use { it.readBytes() } ?: byteArrayOf()

Prompt To Fix With AI

This is a comment left during a code review. Path: apps/android/app/src/main/java/ai/openclaw/app/voice/TalkModeVoiceResolver.kt Line: 89-90 Comment: **Null `errorStream` causes NPE on error responses with no body** `HttpURLConnection.getErrorStream()` returns `null` when the server returns a 4xx/5xx response with no body (per Android docs). On that path `stream` becomes `null`, and `stream.use { it.readBytes() }` will pass `null` as `it` and crash with a `NullPointerException` when `readBytes()` is called on it. Use the safe-call operator and fall back to an empty array so the subsequent error message path still works cleanly: ```suggestion val stream = if (code >= 400) conn.errorStream else conn.inputStream val data = stream?.use { it.readBytes() } ?: byteArrayOf() ``` How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-03-12T07:11:33Z

apps/android/app/src/main/java/ai/openclaw/app/voice/TalkModeVoiceResolver.kt

+      } finally {
+        conn.disconnect()
      }


conn.disconnect() defeats HTTP keep-alive / connection reuse

On Android 4.4+ HttpURLConnection is backed by OkHttp. Simply closing the response stream (already done by stream.use {} above) returns the underlying TCP connection to the pool for keep-alive reuse. Calling conn.disconnect() unconditionally in finally then immediately tears that connection down, which negates the pooling benefit and adds latency for every subsequent call to listVoices().

The finally block is still useful for the case where an exception is thrown before stream is ever opened (e.g. a connection timeout), but in the happy path it is counterproductive. Consider disconnecting only on error, or removing it entirely and relying on stream-close for cleanup:

} catch (e: Exception) { conn.disconnect() throw e }

Prompt To Fix With AI

This is a comment left during a code review. Path: apps/android/app/src/main/java/ai/openclaw/app/voice/TalkModeVoiceResolver.kt Line: 104-106 Comment: **`conn.disconnect()` defeats HTTP keep-alive / connection reuse** On Android 4.4+ `HttpURLConnection` is backed by OkHttp. Simply closing the response stream (already done by `stream.use {}` above) returns the underlying TCP connection to the pool for keep-alive reuse. Calling `conn.disconnect()` unconditionally in `finally` then immediately tears that connection down, which negates the pooling benefit and adds latency for every subsequent call to `listVoices()`. The `finally` block is still useful for the case where an exception is thrown before `stream` is ever opened (e.g. a connection timeout), but in the happy path it is counterproductive. Consider disconnecting only on error, or removing it entirely and relying on stream-close for cleanup: ```kotlin } catch (e: Exception) { conn.disconnect() throw e } ``` How can I resolve this? If you propose a fix, please make it concise.

Kaneki-x · 2026-03-12T07:17:11Z

@greptile-apps Addressed both review comments:

Null errorStream NPE: Changed to stream?.use { it.readBytes() } ?: byteArrayOf() so a null errorStream falls back to an empty byte array instead of crashing.
HTTP keep-alive preservation: Replaced finally { conn.disconnect() } with catch (e: Exception) { conn.disconnect(); throw e } so disconnect() only runs on error. In the happy path, stream.use {} closes the stream and returns the TCP connection to the pool for keep-alive reuse.

Kaneki-x · 2026-03-12T07:25:07Z

@obviyus @steipete Review feedback has been addressed. Could you take a look when you get a chance? Thanks!

obviyus · 2026-03-13T09:29:38Z

Landed on main.

Landed source commit: ef341de
Merge commit: 84428bb

Thanks @Kaneki-x.

* main: (168 commits) fix: stabilize macos daemon onboarding fix(ui): keep shared auth on insecure control-ui connects (openclaw#45088) docs(plugins): clarify workspace shadowing fix(node-host): harden perl approval binding fix(node-host): harden pnpm approval binding fix(discovery): add missing domain to wideArea Zod config schema (openclaw#35615) chore(gitignore): add docker-compose override (openclaw#42879) feat(ios): add onboarding welcome pager (openclaw#45054) fix(signal): add groups config to Signal channel schema (openclaw#27199) fix: restore web fetch firecrawl config in runtime zod schema (openclaw#42583) fix: polish Android QR scanner onboarding (openclaw#45021) fix(android): use Google Code Scanner for onboarding QR fix(config): add missing params field to agents.list[] validation schema (openclaw#41171) docs(contributing): update Android app ownership fix(agents): rephrase session reset prompt to avoid Azure content filter (openclaw#43403) test(config): cover requiresOpenAiAnthropicToolPayload in compat schema fixture fix(agents): respect explicit user compat overrides for non-native openai-completions (openclaw#44432) Android: fix HttpURLConnection leak in TalkModeVoiceResolver (openclaw#43780) Docker: add OPENCLAW_TZ timezone support (openclaw#34119) fix(agents): avoid injecting memory file twice on case-insensitive mounts (openclaw#26054) ...

…w#43780) * Android: fix HttpURLConnection leak in TalkModeVoiceResolver.listVoices * fix null errorStream NPE and preserve HTTP keep-alive * fix: restore voice resolver disconnect cleanup --------- Co-authored-by: Ayaan Zaidi <[email protected]>

…w#43780) * Android: fix HttpURLConnection leak in TalkModeVoiceResolver.listVoices * fix null errorStream NPE and preserve HTTP keep-alive * fix: restore voice resolver disconnect cleanup --------- Co-authored-by: Ayaan Zaidi <[email protected]> (cherry picked from commit 84428bb)

…w#43780) * Android: fix HttpURLConnection leak in TalkModeVoiceResolver.listVoices * fix null errorStream NPE and preserve HTTP keep-alive * fix: restore voice resolver disconnect cleanup --------- Co-authored-by: Ayaan Zaidi <[email protected]>

…w#43780) * Android: fix HttpURLConnection leak in TalkModeVoiceResolver.listVoices * fix null errorStream NPE and preserve HTTP keep-alive * fix: restore voice resolver disconnect cleanup --------- Co-authored-by: Ayaan Zaidi <[email protected]> (cherry picked from commit 84428bb)

openclaw-barnacle bot added app: android App: android size: XS labels Mar 12, 2026

greptile-apps bot reviewed Mar 12, 2026

View reviewed changes

obviyus self-assigned this Mar 13, 2026

Kaneki-x and others added 3 commits March 13, 2026 14:57

Android: fix HttpURLConnection leak in TalkModeVoiceResolver.listVoices

480bd96

fix null errorStream NPE and preserve HTTP keep-alive

14e828c

fix: restore voice resolver disconnect cleanup

ef341de

obviyus force-pushed the fix/android-voice-resolver-conn-leak branch from ef7f7d2 to ef341de Compare March 13, 2026 09:28

obviyus merged commit 84428bb into openclaw:main Mar 13, 2026
6 checks passed

github-actions bot mentioned this pull request Mar 13, 2026

📡 Upstream Digest — 2026-03-13 10:28 UTC curtismercier/openclaw-mods#251

Open

github-actions bot mentioned this pull request Mar 15, 2026

📢 OpenClaw 新版本发布: v2026.3.13-1 xianyu110/awesome-openclaw-tutorial#32

Closed

5 tasks

alexey-pelykh mentioned this pull request Mar 27, 2026

Cherry-pick (repair): 51 commits missing from malformed scan issues #1915/#1916 remoteclaw/remoteclaw#2011

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Android: fix HttpURLConnection leak in TalkModeVoiceResolver#43780

Android: fix HttpURLConnection leak in TalkModeVoiceResolver#43780
obviyus merged 3 commits intoopenclaw:mainfrom
Kaneki-x:fix/android-voice-resolver-conn-leak

Kaneki-x commented Mar 12, 2026

Uh oh!

greptile-apps bot commented Mar 12, 2026

Uh oh!

greptile-apps bot Mar 12, 2026

Uh oh!

greptile-apps bot Mar 12, 2026

Uh oh!

Kaneki-x commented Mar 12, 2026 •

edited

Loading

Uh oh!

Kaneki-x commented Mar 12, 2026

Uh oh!

Uh oh!

obviyus commented Mar 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		val stream = if (code >= 400) conn.errorStream else conn.inputStream
		val data = stream.use { it.readBytes() }

Uh oh!

Conversation

Kaneki-x commented Mar 12, 2026

Summary

Fix

Test plan

Uh oh!

greptile-apps bot commented Mar 12, 2026

Greptile Summary

Confidence Score: 3/5

Uh oh!

greptile-apps bot Mar 12, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Mar 12, 2026

Choose a reason for hiding this comment

Uh oh!

Kaneki-x commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kaneki-x commented Mar 12, 2026

Uh oh!

Uh oh!

obviyus commented Mar 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Kaneki-x commented Mar 12, 2026 •

edited

Loading