Christian Schwarz de780d2e0f make TenantState::{Loading,Attaching,Activating} owned by spawn_load / spawn_attach ...

See the Mermaid diagram in the doc comment for the now-possible state transitions.

The two core insights / changes are:
- spawn_load and spawn_attach own the tenant state until they're done
- once load()/attach() calls are done
    - if they failed, transition them to Broken directly (we know
      that there's no background activity because we didn't call activate yet)
    - if they succeed, call activate. We can make it infallible. How? Later.

- set_broken() and set_stopping() are changed to wait for spawn_load() /
  spawn_attach() to finish. This sounds scary because it might hinder
  detach or shutdown, but actually, concurrent attach+detach, or
  attach+shutdown, or load+shutdown, or attach+shutdown were just racy.
  With this change, they're not anymore.
  We can add a CancellationToken stored in Tenant for load/attach and cancel
  it from set_stopping() or set_broken() if necessary in the future.

So, why can activate() be infallible now: because we declare that
spawn_load and spawn_attach own the tenant state until they're done.
And we enforce that ownership using the wait_for at the start of
set_stopping and set_broken.

2023-05-25 15:02:43 +02:00

..

src

make TenantState::{Loading,Attaching,Activating} owned by spawn_load / spawn_attach

2023-05-25 15:02:43 +02:00

Cargo.toml

Add reason to TenantState::Broken (#3954)

2023-04-13 12:11:43 +03:00