Till Rohrmann

@slinkydeveloper can you resolve my comments and update this PR so that I can rebase #3953 on it?

Until we create the next release, I will enable the debug assertions for release builds hoping that we find another instance of this problem.

Aren't we only sending a `EffectKind::PinnedDeployment` message to the partition processor if there is a JournalEntry to be sent to the partition processor (https://github.com/restatedev/restate/blob/359bb0fa9b306cf65ea4be38a966245a28896c45/crates/invoker-impl/src/lib.rs#L757, https://github.com/restatedev/restate/blob/359bb0fa9b306cf65ea4be38a966245a28896c45/crates/invoker-impl/src/lib.rs#L711, https://github.com/restatedev/restate/blob/359bb0fa9b306cf65ea4be38a966245a28896c45/crates/invoker-impl/src/lib.rs#L808)? Since a `JournalEntry` takes...

Why is it a problem if only the `PinnedDeployment` message gets applied? I assume it would be a problem if the invoker wouldn't see the effect of it before retrying...

> Exactly this. pinned deployment is applied, but while this happens the invoker tries with a different deployment because it hasn't seen yet the update. How can this happen in...

> * pinned deployment sent to the channel, then sent to bifrost immediately > * now the second send from the invoker blocks because IDK channel full, task pre-empted or...

For posterity: The way we ran into this problem was by load-testing a 3 node Restate cluster (dev mode) using the mock-service endpoint. The cluster was in a bad shape...

I think this issue has been superseded by https://github.com/restatedev/restate/issues/2605 and we can close it. Sorry for not properly maintaining it @lsytj0413.

Thanks for picking up this issue @lsytj0413. We were discussing whether making this feature also optional and disabling it by default could be worthwhile as well.

I've rebased it on `main` now.