The fix is to use

start = CoroutineStart.UNDISPATCHED

, but that feels a bit weird

The proper fix is to use

send

instead of

offer

The thing is, I’m sending a command to the actor, but I’d purposely like for the actor to drop this command if it’s busy. I don’t think I can accomplish this with

send

.

In your case the actor was busy starting up 🙂

Thanks for your response. I’ll explain my use-case a bit more. I’m handling some user actions, but sometimes the system sends a bunch of click events really fast. In that case, I’d like for the first one to be processed, but the following calls should be dropped since the first process is still running. If I use a buffered channel, I’ll end up processing the event multiple times because the events will become queued up.

That’s what conflated channels for

But conflated still essentially has a capacity of 1. So if I re-send a command while one is already running, then it’ll re-run it after the first one is done.

If you resend, yes. But it conflates repeated into just one.

I understand, but I’m looking for a behavior where sent events are simply ignored if the previous one is still being processed

I am not sure what exact behavior do you want. Just drop any commands while its running? That’s what default rendezvous done (and you are obviously not happy with it)

I am very happy with it actually 🙂 I’m just surprised that I had to use

UNDISPATCHED

for the initial command in order to make sure that it wasn’t dropped

Because it has to start

Yes I guess I actually understand it now, but it just felt strange seeing that there was this “initialisation” which required special care. Thanks for taking the time to explain. I guess just have to wrap my head around the fact that even though

actor

returns a channel, it’s still just a couroutine builder, so it follows the same principles of asynchronously launching the coroutine which receives from the channel.

Yes. It is