1 Commits

Author	SHA1	Message	Date
ravarora2	2d289f720d	BUZZ-301: Add user deletion request intake (#8496) ... ## 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>	2026-10-22 10:49:27 -04:00