Job lifecycle and cancellation in Kotlin - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this coroutine job cancellation code?

Consider the following Kotlin code using coroutines. What will be printed when this code runs?

Kotlin

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch {
        repeat(3) { i ->
            println("Working on $i ...")
            delay(100L)
        }
    }
    delay(250L)
    job.cancel()
    job.join()
    println("Done")
}

A Working on 0 ...\nWorking on 1 ...\nDone

B Working on 0 ...\nWorking on 1 ...\nWorking on 2 ...\nDone

C Working on 0 ...\nDone

D Done

💡 Hint

Think about when the job is cancelled and how many iterations complete before cancellation.

The job starts and prints 'Working on 0 ...' (~0ms), 'Working on 1 ...' (~100ms), and 'Working on 2 ...' (~200ms), each followed by a 100ms delay. After 250ms, the job is cancelled during the third delay, so no further iterations run. Then 'Done' is printed.

🧠 Conceptual

intermediate

Which state does a Job enter after calling cancel() but before completion?

In Kotlin coroutines, after you call cancel() on a Job but before it finishes, what is the Job's state?

A Active

B Cancelled

C New

D Completing

💡 Hint

Think about the transition phase between active and fully cancelled.

After cancel() is called, the Job enters the 'Completing' state while it finishes its cancellation process. It is not yet fully 'Cancelled' until completion.

🔧 Debug

advanced

Why does this coroutine not cancel as expected?

Examine the code below. The job.cancel() is called, but the coroutine keeps running. Why?

Kotlin

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch {
        for (i in 1..5) {
            Thread.sleep(100L)
            println("Working $i")
        }
    }
    delay(250L)
    job.cancel()
    job.join()
    println("Finished")
}

A delay() inside the coroutine is missing, so cancellation is ignored.

B Thread.sleep blocks the thread and prevents cancellation checks inside the coroutine.

C The coroutine is not cancellable because it uses launch instead of async.

D job.cancel() was called too late after the coroutine finished.

💡 Hint

Consider how blocking calls affect coroutine cancellation.

Thread.sleep blocks the thread and does not check for cancellation, so the coroutine cannot be cancelled during that sleep. Using delay instead allows cancellation.

📝 Syntax

advanced

Which option correctly cancels a Job and waits for its completion?

Select the Kotlin code snippet that cancels a Job and waits until it finishes properly.

A

job.cancel()
job.join()

B

job.cancel()
job.cancelAndJoin()

C job.cancelAndJoin()

D

job.join()
job.cancel()

💡 Hint

Look for the built-in function that combines cancel and join.

cancelAndJoin() cancels the job and suspends until it completes. Calling cancel() then join() separately works but is less concise. Option C is the idiomatic way.

🚀 Application

expert

How many times will 'Task running' print before cancellation?

Given the code below, how many times will 'Task running' be printed before the job is cancelled?

Kotlin

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch {
        repeat(10) { i ->
            if (!isActive) return@launch
            println("Task running $i")
            delay(50L)
        }
    }
    delay(230L)
    job.cancelAndJoin()
    println("Job cancelled")
}

A 5

B 6

C 4

D 7

💡 Hint

Calculate how many 50ms delays fit into 230ms before cancellation.

Each iteration delays 50ms. After 230ms, about 4 full iterations complete and the 5th starts. The 5th prints before cancellation, so total prints are 5.

Practice

1. Which of the following best describes the lifecycle of a Kotlin Job?

easy

A. A job is always active and never completes.

B. A job starts cancelled and then becomes active.

C. A job starts active, can be cancelled, and then completes.

D. A job completes before it starts.

Solution

1. Step 1: Understand Job lifecycle states

   A Kotlin Job begins in an active state, meaning it is running or ready to run.

2. Step 2: Recognize cancellation and completion

   A Job can be cancelled to stop its work, and after finishing or cancellation, it reaches a completed state.

3. Final Answer:

   A job starts active, can be cancelled, and then completes. -> Option C

4. Quick Check:

   Job lifecycle = active -> cancelled -> completed [OK]

Hint: Jobs start active, then cancel or complete [OK]

Common Mistakes:

• Thinking jobs start cancelled
• Assuming jobs never complete
• Confusing job states order

2. Which Kotlin code snippet correctly cancels a job and waits for its completion?

easy

A. job.cancelAndJoin()

B. job.cancel()

C. job.start()

D. job.join()

Solution

1. Step 1: Identify cancellation with waiting

   The method cancelAndJoin() cancels the job and suspends until it finishes.

2. Step 2: Differentiate from other methods

   cancel() only requests cancellation without waiting; join() waits but doesn't cancel; start() begins a job.

3. Final Answer:

   job.cancelAndJoin() -> Option A

4. Quick Check:

   Cancel and wait = cancelAndJoin() [OK]

Hint: Use cancelAndJoin() to cancel and wait [OK]

Common Mistakes:

• Using cancel() without waiting
• Confusing join() with cancel
• Calling start() to cancel

3. What will be the output of this Kotlin coroutine code?

val job = CoroutineScope(Dispatchers.Default).launch {
    repeat(3) { i ->
        println("Working on $i...")
        delay(100)
    }
}
job.cancel()
Thread.sleep(500)

medium

A. Prints all three "Working on" lines

B. Prints some "Working on" lines before stopping

C. Throws a cancellation exception

D. Prints no output

Solution

1. Step 1: Analyze job launch and cancellation

   The job starts and prints "Working on 0...", then delays. The cancel() is called immediately after launch.

2. Step 2: Understand cancellation effect

   Because cancellation happens quickly, some iterations may run before the job stops, so partial output appears.

3. Final Answer:

   Prints some "Working on" lines before stopping -> Option B

4. Quick Check:

   Partial output due to quick cancel [OK]

Hint: Cancel stops job but may print partial output [OK]

Common Mistakes:

• Expecting all lines printed
• Expecting no output at all
• Assuming exception is printed

4. Identify the error in this Kotlin coroutine cancellation code:

val job = CoroutineScope(Dispatchers.Default).launch {
    try {
        repeat(5) {
            println("Working...")
            delay(100)
        }
    } catch (e: Exception) {
        println("Cancelled")
    }
}
job.cancelAndJoin()

medium

A. Missing job.start() before cancel

B. cancelAndJoin() should be called inside launch

C. delay() cannot be used inside launch

D. Catching Exception does not handle cancellation properly

Solution

1. Step 1: Understand cancellation exception type

   Cancellation throws CancellationException, which is a subclass of Throwable but not Exception.

2. Step 2: Recognize catch block limitation

   Since CancellationException is not caught by catch (e: Exception), the cancellation is not handled as intended.

3. Final Answer:

   Catching Exception does not handle cancellation properly -> Option D

4. Quick Check:

   Catch CancellationException, not Exception [OK]

Hint: Catch CancellationException, not Exception [OK]

Common Mistakes:

• Catching Exception instead of CancellationException
• Calling cancelAndJoin() incorrectly
• Thinking delay() is invalid inside launch

5. You want to safely cancel a long-running job and perform cleanup after cancellation. Which Kotlin coroutine pattern achieves this correctly?

hard

A. Use job.cancelAndJoin() then run cleanup code after it returns.

B. Call job.cancel() and immediately start a new job for cleanup.

C. Ignore cancellation and let the job finish naturally.

D. Call job.join() without cancelling, then cleanup.

Solution

1. Step 1: Understand safe cancellation

   Using cancelAndJoin() cancels the job and waits until it fully stops, ensuring no work is left running.

2. Step 2: Perform cleanup after cancellation

   After cancelAndJoin() returns, it's safe to run cleanup code because the job is fully cancelled.

3. Final Answer:

   Use job.cancelAndJoin() then run cleanup code after it returns. -> Option A

4. Quick Check:

   Cancel and wait before cleanup = cancelAndJoin() [OK]

Hint: Cancel and wait before cleanup with cancelAndJoin() [OK]

Common Mistakes:

• Starting cleanup before job stops
• Ignoring cancellation
• Using join() without cancelling