Non-JSON server response in Transport.processResponse() causes permanent networking deadlock via uncaught JSONException

[DanBoSlice]

When the Countly server returns a non-JSON response (e.g., an HTML page from a 502 Bad Gateway or 503 Service Unavailable), Transport.processResponse() throws a JSONException that is not caught by Transport.send(). This uncaught exception prevents Tasks.running from being reset to null, causing Tasks.isRunning() to return true permanently. As a result, DefaultNetworking.check() never submits new send tasks, and the entire networking queue is deadlocked until the SDK is reinitialized.

Root Cause

Transport.processResponse() unconditionally parses the response body as JSON:

// Transport.java — processResponse()
JSONObject json = new JSONObject(response);  // throws JSONException on HTML/non-JSON

Transport.send() catches only IOException:

// Transport.java — send()
try {
    // ... HTTP request and processResponse() call
} catch (IOException e) {
    // handles network errors
}
// JSONException (extends RuntimeException) is NOT caught

The exception propagates up to Tasks, where the executor wrapper has:

// Tasks.java — task execution
running = task.id;    // ← set before execution
task.run();           // ← exception thrown here
running = null;       // ← NEVER reached (not in a finally block)

Since running is never reset, Tasks.isRunning() returns true forever, and DefaultNetworking.check() skips submitting new tasks.

Steps to Reproduce

1. Initialize the Countly SDK
2. Queue some events/requests
3. Have the Countly server return a non-JSON response (e.g., a reverse proxy returning 502/503 HTML)
4. Observe that isSending() returns true permanently and no further requests are ever sent

Expected Behavior

1. Transport.send() should catch RuntimeException (or at minimum JSONException) in addition to IOException, treating non-JSON responses as a transient failure with retry.
2. Tasks should reset running = null in a finally block to ensure the executor never gets permanently stuck regardless of exception type.

[arifBurakDemiray]

Hello @DanBoSlice 🙌

Thanks for the report! We've identified and fixed the root cause.

The problem was a chain of three things:

• Transport.processResponse() was calling new JSONObject(response) without a try-catch so an HTML 502 page would throw a JSONException
• Transport.send() only caught IOException, so the JSONException (a RuntimeException) would escape
• Tasks.run() didn't clean up the running state in a finally block, so the exception left isSending() permanently stuck as true

The fix:

• Wrapped the JSON parsing in processResponse() with a try-catch, non-JSON responses now gracefully return false
• Added a null check for when response() returns null on I/O errors
• Added a broader catch(Exception) in send() as a safety net
• Moved the executor state cleanup into a finally block so running is always reset, regardless of what exception occurs
• Made the running field volatile for proper cross-thread visibility

We've also added 30 tests covering this scenario, including end-to-end tests with a mock HTTP server that returns HTML 502 responses.

The fix is in this PR and will be included in the next release: #267

Thanks again for flagging this, reports like yours help us make the SDK better for everyone! Let us know if you run into anything else. 🙏

[DanBoSlice]

@arifBurakDemiray Thanks for the super quick response! Honestly didn't expect that 🙂

[arifBurakDemiray]

Hello @DanBoSlice 🙌

It is a pleasure for us to help 🙇 We are truly flattered to hear such gracious words 🙂
Thank you so much.

I also want to let you know that we have released Java SDK 24.1.5, which encompasses the fix for the issue.
https://github.com/Countly/countly-sdk-java/releases/tag/24.1.5

Have a great day!