diff --git a/content/post/2024/03/the-case-of-a-leaky-goroutine.md b/content/post/2024/03/the-case-of-a-leaky-goroutine.md
index 54828103..47f7c2da 100644
--- a/content/post/2024/03/the-case-of-a-leaky-goroutine.md
+++ b/content/post/2024/03/the-case-of-a-leaky-goroutine.md
@@ -50,7 +50,7 @@ func ToDoneInterface(done <-chan struct{}) <-chan interface{} {
 }
 ```
 
-The `defer close()` seems to close well, but it's on the wrong channel. The `select{}` will wait until it received a signal from `done`: that's either when something is sent or when a `close()` has been called (a `nil` value). So, the Goroutine closes the channel **after** the first received `struct{}` on the passed `done` channel. If we pass the same channel multiple times---which we do---and that channel lives longer than is the case wich `ctx.Done()`---which it is---this Goroutine will leak.
+The `defer close()` seems to close well, but it's on the wrong channel. The `select{}` will wait until it received a signal from `done`: that's either when something is sent or when a `close()` has been called (a `nil` value). So, the Goroutine closes the channel **after** the first received `struct{}` on the passed `done` channel. If we pass the same channel multiple times---which we do---and that channel lives longer than is the case which `ctx.Done()`---which it is---this Goroutine will leak.
 
 I don't know if that all makes sense if you're not familiar with Go, or even if you are. I know I had to stare at the above code block for a good hour and its usage context (got it, `Context`? Go-joke!) before realizing something wasn't as it was supposed to be here.