Does start_link returning mean the cache is warm?

Maybe the service doesn't have to hold anything. If clients already understand Warming, report it through readiness and let each one retry under its own limit. That's one less queue to explain, and this one would only exist to get through startup. If some client really can't retry, fine, add the wait. Give it a capacity and write down what a full queue tells the next caller, so saturation gets an answer right away instead of a hang.

The waiting option has two events to order, the caller's timeout and the removal of its pending request. The caller times out. Warming finishes. The server goes through its waiting entries and replies to this one before it gets to the withdrawal message. What happens then has to be defined.

Move the withdrawal one step earlier and it reaches the server while warming is still running. Then the server has to find that caller's entry and drop it, so every entry needs a reference the withdrawal can name. In the first order the caller has the work instead. It gets a reply to a request it gave up on and has to recognize it and throw it away. Both orders need handling, and the waiting set still needs its own bound.

Go is what I'd reach for here, and there a ready channel covers both of Vadim's cases. The warm-up goroutine closes it when it finishes, and a readiness check is a non-blocking receive.

go func() {
	warm(cache)
	close(ready)
}()

select {
case <-ready:
	// serve from the cache
default:
	// report Warming
}

Anyone who wants to wait just receives. A closed channel releases every receiver at once. The waiting set is then blocked goroutines, which is fine until request handlers pile up behind it, and then you're back at the capacity question.

A call that arrives during warming just waits. init returns the continue, and the continue runs before the server reads its mailbox, so a GenServer.call(pid, :get) sent right after start_link returns comes back once warming finishes. Stretch the warming past the default timeout and the call exits instead.

So started really is the honest word for what start_link promised. The timeout is the only thing that tells the client the difference, and a timeout is a sad path, not a status. I'm back to wanting Warming as an answer the server gives.