Tenant onboarding: validate, provision and retry

Current snapshot

Provision one tenant from one stable request

This experiment onboards fictional tenant alpha using a stable request key, alpha:onboard:42. A resource ledger holds the allocated tenant ID, owning tenant, storage binding and readiness flag. Creation and readiness are separate decisions: an allocated resource is not ready until its storage probe succeeds. The experiment actually adds and updates local ledger entries, so a repeated request can be inspected by resource ID instead of a success message alone. No cloud account, database, billing system or ADK runtime is contacted. Authenticated identity and permission to administer alpha are assumptions of the fixture.

Validate a binding before allocating anything

Storage binding selects alpha, beta or missing. Only alpha passes the fixed ownership check. Missing and beta bindings both stop before allocation, regardless of retry policy, probe failure or submission count. Run beta with two submissions and inspect zero resources and zero probe calls. This prevents a mistaken cross-tenant binding from looking like a successful setup. The ownership names are trusted fixture inputs, not a substitute for server-side authorization. Real provisioning also checks quota, region, policy, billing and whether the referenced resource still exists.

Reproduce a failed first-use probe

Probe behavior selects All probes pass or First probe fails. Submissions chooses Once or Twice. With alpha, stable-key reuse, first failure and one submission, tenant-alpha-1 exists but remains non-ready. The final status is probe failed; allocation has not been rolled back. Select two submissions: the second attempt finds the same resource by request key, runs another probe and changes that single record to ready. Probe calls becomes two, reused becomes one and resource count remains one. This is a deterministic injected failure, not a health test against a real storage endpoint or a latency measurement.

Compare retries with blind allocation

Retry policy chooses Reuse the stable request key or Allocate on every submission. Keep two submissions and the first probe failure. Blind allocation creates tenant-alpha-1 and tenant-alpha-2. The first remains non-ready while the second becomes ready, and reconciliation reports duplicate allocation. If all probes pass, both become ready, which still represents duplicate infrastructure for one intended request. A healthy second resource does not erase the first. The model deliberately performs no automatic cleanup so the remaining resources stay visible. In production, durable request records and atomic uniqueness are needed; this single-threaded in-memory lookup is not a distributed idempotency implementation.

Inspect decisions rather than only the final banner

Play reveals eight decisions over sixty inspection seconds and Pause holds the view. Next event advances to the next boundary. Restart retains scenario choices while rewinding. Time seeks and pauses, and Speed offers quarter, half, normal and double inspection pace. A choice change resets playback; hidden tabs pause. Export events JSON contains the full trace and current prefix. Capture baseline stores choices and the inspected result, Replace baseline updates it and Clear baseline removes it. Notebook observations persist locally, Export notes downloads them, and Expand experiment toggles full screen. The event history supports keyboard scrolling.

Recognize recovery and security limits

The two attempts are sequential submissions using identical configuration and the same key. There is no concurrent race, changed-payload reuse, lost response, timeout, key expiry, rollback failure or durable recovery after a browser crash. A real idempotency service must reject incompatible reuse and protect request records across process restarts. The storage probe is a boolean fixture outcome; it does not prove permanent availability. Non-ready resources remain allocated, which is why the visible ledger matters for cleanup. Related deployment and tenant-data readings give operational context, while this experiment isolates validation, allocation identity, retries and readiness.