mirror of
https://github.com/block/buzz.git
synced 2026-10-30 14:01:37 +00:00
8caf8351c1
## Summary
User deletion needs to delegate owned communities to the existing
community deletion process and report what is still waiting. This adds
the standalone components for that flow; wiring them into the user
workflow is a later change.
The owned-community handler checks for an existing community deletion
request first. If none exists, it calls `submit_and_prepare`, the same
function used by the community CLI. The handler saves the child request
ID, last observed status, and operator instructions on the existing user
stage. Community approval and execution remain separate. Repeated or
concurrent calls reuse the existing child without resetting its approval
or execution state. The user stage follows the current request for its
approved community ID. If an operator aborts A and submits B for that
community, the next invocation saves B on the same stage row.
An unfinished child leaves the user stage waiting. A later handler
invocation refreshes its observation and completes the stage when the
child reaches logical completion (`retention_pending` with a completion
timestamp). Retained-copy obligations remain visible in the saved
result. Lease owner and generation checks protect stage updates.
The separate summary handler reads only the user request, approval, and
stage tables. It lists unfinished stages, saved external waits and
operator actions, completed results, and inventory communities not yet
reached. It never queries or refreshes community deletion state, so
child statuses are explicitly labeled as last observed.
### Scope and rollout
- No migrations, new HTTP endpoints, CLI commands, or worker dispatch
changes. Owned-community intake remains disabled.
- Waiting uses the existing stage status plus `metadata_json.waiting`.
This slice does not advance past waiting stages. Integration must add an
explicit resume or bounded revisit cadence before enabling automatic
scheduling.
- The CLI and user handler share the existing database submission,
inventory building, and inventory freezing operations. There is no API
wrapper class or second insertion path. Preparation failures leave a
durable child request and a retry record on the user stage; subsequent
lookup exposes instructions for the operator to finish preparation.
Guidance distinguishes operator-origin preparation, automatic
owner-origin preparation, blocked requests that need remediation and
`unblock`, and aborted requests that can be replaced.
- Existing submission accepts a host for the CLI or an immutable
community ID for the parent. A transaction protects target resolution
and admission. ID-pinned calls never replace an existing child, even an
aborted one. Inventory helpers take their store and media dependencies
directly. Successful stage persistence clears any saved waiting marker.
- These components become available to callers after release but are not
scheduled by the relay or user worker. No data migration is needed to
roll back this change.
See [the implementation and testing
guide](0cc24ecd9c/docs/user-deletion-owned-community-handlers.md)
for entry points, saved fields, failure recovery, and the remaining
integration work.
### Related issue
Follows #8520 (saved user-deletion stage transitions). Related inventory
work: #8605. Searched existing PRs; no duplicate standalone
owned-community handler found.
### Testing
The owned-community handler is intentionally not wired into the user
CLI. The existing community CLI now calls the shared submission
function. The guide provides the isolated PostgreSQL test command,
exercising the shared submission function, owned-community handler, and
summary with a loopback object-storage fixture. Tests seed owned
inventory directly and simulate child completion; they do not run
destructive community deletion.
Coverage includes separate approval, repeated and concurrent submission,
preparation failure recovery, stale saved summaries, child completion,
aborted children, same-owner stale generations, and persisted-input
validation. Additional cases cover concurrent CLI/parent submission, CLI
preparation retry, host/ID mismatch before insertion, and database
failures that must propagate despite an existing child.
All 15 focused PostgreSQL tests passed: 13 owned-community cases and
both community fence-retention schema cases. New coverage exercises A →
abort → B on the same user stage, an operator transition during
inventory listing, and operator guidance. Temporarily restoring the old
child-ID rejection and removing the freeze fallback each made its
regression test fail; both mutations were then reverted.
All pre-push hooks passed on `0cc24ecd9`, including workspace Rust and
desktop Tauri checks. The additional local `just ci` and `just test`
runs are still in progress.
Generated with Codex
---------
Signed-off-by: Ravneet Arora <rarora@squareup.com>