Fixing "Inappropriate Blocking Method Call" in Kotlin Coroutines

By the end of this page, you will understand why Kotlin warns about blocking method calls inside coroutines, when that warning matters, and how to fix it properly using the right coroutine dispatcher such as Dispatchers.IO. You will also see how this applies to common libraries like OkHttp and Moshi, plus common mistakes to avoid.

In Kotlin coroutines, not all threads are meant for blocking work.

A blocking call is a function that keeps the current thread busy until it finishes. Examples include:

• Network requests using blocking APIs such as OkHttpClient.newCall(...).execute()
• Reading files from disk
• Database calls in blocking drivers
• Heavy parsing or serialization in some situations

Coroutines are lightweight, but the code inside them still runs on real threads. If you call a blocking method on a thread that should stay free, you can reduce performance or freeze important work.

That is why the IDE warns about "inappropriate blocking method call".

Why the warning appears

The warning usually appears when you call a known blocking API from a coroutine running on a dispatcher that is not intended for blocking operations, such as:

• Dispatchers.Default for CPU-bound work
• Dispatchers.Main for UI work

Blocking on these dispatchers is a problem because:

• Dispatchers.Main can freeze the UI
• Dispatchers.Default has a limited pool meant for computation, so blocking it can starve CPU tasks

The usual fix

Move blocking work to Dispatchers.IO:

suspend : String = withContext(Dispatchers.IO) {
     response = okHttpClient.newCall(request).execute()
    response.body!!.string()
}

Think of coroutine dispatchers like different workstations in an office:

• Dispatchers.Main is the front desk. It must stay responsive.
• Dispatchers.Default is the analysis team. They do thinking and calculations.
• Dispatchers.IO is the back office for slow external tasks like waiting on files or network responses.

If you make the front desk employee wait on a package delivery for 10 minutes, nobody can greet visitors.

If you make the analysis team sit and wait on network calls, they stop doing useful computation.

So when a method blocks, send it to the back office: Dispatchers.IO.

The core tool for moving work to the correct dispatcher is withContext.

Basic syntax

suspend fun example(): Result = withContext(Dispatchers.IO) {
    // blocking code here
    blockingCall()
}

Example with OkHttp

suspend fun fetchUserJson(client: OkHttpClient, request: Request): String {
    return withContext(Dispatchers.IO) {
        client.newCall(request).execute().use { response ->
            if (!response.isSuccessful) {
                throw IOException("Unexpected HTTP ${response.code}")
            }
            response.body?.string() ?: throw IOException("Empty response body")
        }
    }
}

Why this works

• execute() is a blocking network call
• withContext(Dispatchers.IO) runs that block on a dispatcher meant for blocking I/O
• use ensures the response is closed properly

Consider this function:

suspend fun fetchTitle(client: OkHttpClient, request: Request): String {
    return withContext(Dispatchers.IO) {
        client.newCall(request).execute().use { response ->
            response.body?.string() ?: ""
        }
    }
}

Here is what happens step by step:

1. fetchTitle() is called from a coroutine.
2. withContext(Dispatchers.IO) suspends the current coroutine and schedules the block on an I/O thread.
3. client.newCall(request).execute() starts a blocking HTTP request.
4. The I/O thread waits for the server response.
5. Once the response arrives, response.body?.string() reads the response body.
6. use closes the response automatically.
7. The result string is returned from the withContext block.
8. The coroutine resumes with that string.

Why this is safe

The coroutine is still written in a sequential style, but the blocking work happens on a dispatcher built for it.

What would be risky

suspend : String {
     client.newCall(request).execute().body!!.string()
}

Blocking calls inside coroutines appear often in real programs.

HTTP requests

withContext(Dispatchers.IO) {
    client.newCall(request).execute()
}

Used in:

• REST API clients
• internal service calls
• downloading files

File reading and writing

val text = withContext(Dispatchers.IO) {
    File("config.json").readText()
}

Used in:

• configuration loading
• log processing
• import/export tools

Database access with blocking drivers

val user = withContext(Dispatchers.IO) {
    userRepository.findById(1)
}

Used in:

• server-side applications
• desktop apps
• Android apps using older or blocking persistence APIs

JSON parsing after network access

Moshi often appears right after an HTTP response is read. Developers frequently keep the fetch and parse steps together, especially when the payload is small.

Legacy library integration

Coroutines are often added to an existing codebase that already uses blocking Java libraries. withContext(Dispatchers.IO) is the standard bridge.

In real projects, developers usually do not scatter raw blocking calls everywhere. They wrap them in well-defined suspend functions.

Common pattern: repository wrapper

class UserRepository(
    private val client: OkHttpClient,
    private val adapter: com.squareup.moshi.JsonAdapter<User>
) {
    suspend fun fetchUser(request: Request): User = withContext(Dispatchers.IO) {
        client.newCall(request).execute().use { response ->
            if (!response.isSuccessful) {
                throw IOException("HTTP ${response.code}")
            }

            val json = response.body?.string() ?: throw IOException("Empty body")
            adapter.fromJson(json) ?: throw IOException("Invalid JSON")
        }
    }
}

This keeps blocking details in one place.

Guard clauses for validation

suspend fun fetchUser(request: Request?): User {
    requireNotNull(request) { "Request must not be null" }
    return withContext(Dispatchers.IO) {
        
        TODO()
    }
}

1. Calling blocking code directly from a suspend function

A suspend function is not automatically non-blocking.

Broken example:

suspend fun load(): String {
    return client.newCall(request).execute().body!!.string()
}

Why it is a problem:

• suspend only means the function can suspend
• it does not magically move work off the current thread

Fix:

suspend fun load(): String = withContext(Dispatchers.IO) {
    client.newCall(request).execute().use { response ->
        response.body?.string() ?: ""
    }
}

2. Using Dispatchers.Default for blocking I/O

Broken example:

withContext(Dispatchers.Default) {
    client.newCall(request).execute()
}

Why it is a problem:

• Default is for CPU-bound tasks

suspend vs withContext

withContext(Dispatchers.IO) {
    // blocking I/O work
}

Quick rules

• suspend does not mean non-blocking by itself
• Blocking network calls -> Dispatchers.IO
• Blocking file/database calls -> Dispatchers.IO
• CPU-heavy parsing/computation -> Dispatchers.Default
• UI updates -> Dispatchers.Main

Safe OkHttp pattern

suspend fun fetch(): String = withContext(Dispatchers.IO) {
    client.newCall(request).execute().use { response ->
        if (!response.isSuccessful) throw IOException("HTTP ${response.code}")
        response.body?.string() ?: throw IOException("Empty body")
    }
}

Common warning meaning

Inappropriate blocking method call usually means:

• you are calling a blocking API
• the current thread may not be appropriate for blocking work

Remember

Why do I get "inappropriate blocking method call" in a coroutine?

Because the method you are calling blocks the thread, and the current dispatcher may not be intended for blocking work.

Is a suspend function automatically safe for blocking code?

No. A suspend function can still block the thread if you call a blocking API directly.

Should I always use Dispatchers.IO with OkHttp?

If you are using the blocking execute() method, yes, that is the normal choice.

Should Moshi run on Dispatchers.IO or Dispatchers.Default?

It depends. If the work includes blocking stream or response reading, use IO. If it is just heavy parsing of in-memory data, Default may fit better.

Can I ignore the warning?

Only if you are certain the code is already running on a suitable thread. In most cases, it is better to fix the dispatcher explicitly.

Is Dispatchers.Default faster than Dispatchers.IO?

Not for blocking I/O. Default is tuned for CPU-bound work, while IO is designed for blocking operations.

• Kotlin coroutines — The warning only makes sense in the context of coroutine execution.
• Dispatchers.IO — The main dispatcher used for blocking I/O operations.
• Dispatchers.Default — Important for understanding the difference between CPU work and I/O work.
• Suspend functions — Many beginners assume suspend automatically prevents blocking.
• Blocking vs non-blocking code — This is the core idea behind the warning.
• OkHttp — A common source of blocking network calls in Kotlin projects.
• Moshi — Often used together with network responses and parsing.
• withContext — The standard coroutine tool for switching to the correct dispatcher.