mirror of
https://github.com/block/buzz.git
synced 2026-10-27 12:40:30 +00:00
2d289f720d
## Summary
Add the first testable piece of user deletion: submit a synthetic
request, list requests, and inspect one by UUID. Operators can verify
that intake reaches PostgreSQL before we add inventory, approval, and
execution.
Add one operator-global `entity_deletion_requests` table with an
additive migration and matching desired-state schema. Identical
submissions return the same row. Conflicting submissions fail without
changing it. Only `demo:` targets are accepted, and requests stay
`submitted`.
Keep the commands in `buzz-deletion`, reached through a thin `buzz-admin
user-deletions` adapter. Reuse the existing database connection setup.
This change adds no worker, stage history, community gates, or deletion
operations.
### Rollout plan
This is an expand-only schema change plus an operator CLI. Existing
relay code does not use the new request table. No backfill or real
deletion is part of this release.
1. **Order the PRs.** Land #8496 first, using 0068; main now owns 0067
for channel join roles. Rework #8489 to build on this table with the
next available migration number. Renumbering its existing CREATE TABLE
migration alone is insufficient; both PRs currently create the same
request table.
2. **Apply on staging.** For deployments that manage schema separately,
apply the reviewed additive migration before using the new CLI. Where
auto-migration is enabled, the new relay binary applies it at startup.
Keep existing tables and records unchanged.
3. **Verify on staging.** Use the new `buzz-admin` binary with
`DATABASE_URL` pointing to staging. Submit a unique synthetic label,
list requests, and inspect the returned UUID:
```bash
buzz-admin user-deletions submit --target demo:staging-intake-1
--requested-by <operator>
buzz-admin user-deletions list --limit 5
buzz-admin user-deletions inspect <returned-uuid>
```
Verify one `entity_deletion_requests` row with status `submitted`.
Repeat the identical submission and verify the same UUID and timestamps.
Use a new label if this label was used by an earlier staging test.
4. **Apply beyond staging.** After verification, use the deployment's
reviewed schema/release workflow to add the table in the remaining
environments. Requests run only through the operator CLI; this release
starts no deletion worker. No feature flag is needed for this synthetic
intake: the database accepts only `demo:` targets, and real deletion is
absent.
5. **Rollback.** Keep the additive table and saved requests; stop using
the new commands and roll back the binary if needed. After 0068 is
applied, an older binary with auto-migration enabled can fail at startup
with sqlx `VersionMissing`. A binary rollback therefore requires
migration execution to be disabled on the older relay
(`BUZZ_AUTO_MIGRATE=false`, including the corresponding deployment
configuration).
### Related work
This is a smaller first slice of the full-workflow draft
[#8489](https://github.com/block/buzz/pull/8489), which is preserved for
later extraction. The two PRs overlap and should not both be merged as
written.
### Testing
The author submitted `demo:rarora-manual-1` to a separate local
PostgreSQL 17 database. Repeating the same submission returned its
original UUID and timestamps. List, inspect, and a direct SQL query all
returned the same saved request.
<details>
<summary>Actual command inputs and outputs</summary>
Commands ran from the new worktree with `DATABASE_URL` set to the local
`buzz_user_deletion_submit` database. Outputs below are stdout;
connection diagnostics on stderr are omitted.
**Submit again — returns the existing request without creating a
duplicate**
```bash
./target/debug/buzz-admin user-deletions submit \
--target demo:rarora-manual-1 --requested-by rarora
```
```json
{
"id": "2e5bcdec-ab68-44d2-9743-1dd9fa7d2f89",
"entity_type": "user",
"target": "demo:rarora-manual-1",
"status": "submitted",
"requested_by": "rarora",
"reason": null,
"created_at": "2026-10-20T19:57:44.516698Z",
"updated_at": "2026-10-20T19:57:44.516698Z"
}
```
**List saved requests**
```bash
./target/debug/buzz-admin user-deletions list --limit 5
```
```json
[
{
"id": "2e5bcdec-ab68-44d2-9743-1dd9fa7d2f89",
"entity_type": "user",
"target": "demo:rarora-manual-1",
"status": "submitted",
"requested_by": "rarora",
"reason": null,
"created_at": "2026-10-20T19:57:44.516698Z",
"updated_at": "2026-10-20T19:57:44.516698Z"
}
]
```
**Inspect one request**
```bash
./target/debug/buzz-admin user-deletions inspect 2e5bcdec-ab68-44d2-9743-1dd9fa7d2f89
```
```json
{
"id": "2e5bcdec-ab68-44d2-9743-1dd9fa7d2f89",
"entity_type": "user",
"target": "demo:rarora-manual-1",
"status": "submitted",
"requested_by": "rarora",
"reason": null,
"created_at": "2026-10-20T19:57:44.516698Z",
"updated_at": "2026-10-20T19:57:44.516698Z"
}
```
**Read the table directly**
```bash
docker exec buzz-user-deletion-dev-20261020 \
psql -X -U buzz -d buzz_user_deletion_submit -c \
"SELECT id, entity_type, target, status, requested_by
FROM entity_deletion_requests ORDER BY created_at DESC;"
```
```text
id | entity_type | target | status | requested_by
--------------------------------------+-------------+----------------------+-----------+--------------
2e5bcdec-ab68-44d2-9743-1dd9fa7d2f89 | user | demo:rarora-manual-1 | submitted | rarora
(1 row)
```
</details>
A separate CLI smoke test also verified that a conflicting operator and
a non-demo target fail without changing the saved request. The existing
community-deletion `list --limit 1` command passed against the smoke
database.
See [the intake
walkthrough](729233c726/docs/operator-user-deletion-intake.md)
for setup, commands, expected fields, and the SQL query.
Generated with Codex
---------
Signed-off-by: Ravneet Arora <rarora@squareup.com>
73 lines
2.5 KiB
Markdown
73 lines
2.5 KiB
Markdown
# Submit a synthetic user-deletion request
|
|
|
|
This first slice saves and reads requests. It does not discover users, build
|
|
inventory, approve requests, start workers, or delete data. Only synthetic
|
|
`demo:` labels are accepted.
|
|
|
|
## Prepare a local database
|
|
|
|
From the repository root, activate Hermit and start a separate PostgreSQL
|
|
container. These are disposable local credentials.
|
|
|
|
```bash
|
|
. ./bin/activate-hermit
|
|
docker run --detach --name buzz-user-deletion-intake \
|
|
--publish 127.0.0.1:55433:5432 \
|
|
--env POSTGRES_USER=buzz \
|
|
--env POSTGRES_PASSWORD=buzz-local-demo \
|
|
--env POSTGRES_DB=buzz postgres:17-alpine
|
|
export DATABASE_URL=postgres://buzz:buzz-local-demo@127.0.0.1:55433/buzz
|
|
cargo build -p buzz-admin
|
|
# Wait for "accepting connections" before migrating.
|
|
docker exec buzz-user-deletion-intake pg_isready -U buzz -d buzz
|
|
./target/debug/buzz-admin migrate
|
|
```
|
|
|
|
Use an unused port and container name if these are occupied. The commands below
|
|
need only PostgreSQL; a relay, Redis, and object storage are unnecessary.
|
|
|
|
## Submit and see the row
|
|
|
|
```bash
|
|
./target/debug/buzz-admin user-deletions submit \
|
|
--target demo:alice --requested-by operator-a
|
|
```
|
|
|
|
The command prints the saved row as JSON. It contains:
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| `id` | New UUID; copy this for inspection |
|
|
| `entity_type` | `user` |
|
|
| `target` | `demo:alice` |
|
|
| `status` | `submitted` |
|
|
| `requested_by` | `operator-a` |
|
|
| `reason` | `null`, unless supplied with `--reason` |
|
|
| `created_at` | Submission time |
|
|
| `updated_at` | Same time; no execution has started |
|
|
|
|
List recent requests, then inspect the UUID returned above:
|
|
|
|
```bash
|
|
./target/debug/buzz-admin user-deletions list --limit 10
|
|
REQUEST_ID=<returned-uuid>
|
|
./target/debug/buzz-admin user-deletions inspect "$REQUEST_ID"
|
|
```
|
|
|
|
To see the PostgreSQL row directly:
|
|
|
|
```bash
|
|
docker exec buzz-user-deletion-intake psql -X -U buzz -d buzz -c \
|
|
"SELECT id, entity_type, target, status, requested_by, created_at
|
|
FROM entity_deletion_requests ORDER BY created_at DESC;"
|
|
```
|
|
|
|
Exactly one row is saved in `entity_deletion_requests`. Repeating the same
|
|
target, operator, and reason returns that row without changing its timestamps.
|
|
Reusing the target with a different operator or reason fails and preserves the
|
|
original row. Use a new `demo:` label for a new request.
|
|
|
|
This slice stops at `submitted`. Inventory, approval, stage history, worker
|
|
ownership, and execution will be added in later changes. Their fields and tables
|
|
can be added through normal additive migrations.
|