Francesco Guardiani

I'm gonna increase the timeout of this one, because it seems just to be slow. If you look at the timings of the start of the test, you see it...

> Alternatively, we don't rely on individual timers for cleaning up completed invocations. I wonder whether this is all in all a better solution, we register just one periodic timer...

My proposal for this is the following: The leader, once elected, starts a tokio task that periodically reads from rocksdb those scheduled invocations, and self proposes deletions of the old...

I'm ok with both approaches, although for the time being I would vow on proposing all the invocation ids to purge, as this won't need a new command, because `Command::PurgeInvocation`...

In order to trigger this, you also sent the request with idempotency id i assume?

I investigated this, it needs a bit of internal refactoring of invocations in scheduled state. We need to introduce `InvocationStatus::Scheduled`, which comes before Inboxed as state transition.

Summary of the offline discussion: * It makes sense to introduce a variant `InvocationStatus::Scheduled`, this has also some side benefits/fixes that we get for free (be able to cancel/kill scheduled...

> The migration step is probably optional if we want to remove the old invocation status table in version 1.3 and want to be sure that there are no old...

FYI we're working on this.

Dropping some design decisions here. There will be 3 knobs: * `idempotency_retention` (the one we already got) * `workflow_completion_retention` * `journal_retention` There's also the invariant that `idempotency_retention` and `workflow_completion_retention` should...