fix(binjovi): revoke write authorization for a dropped repository #720
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/prune-integration-repos"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Removing a repository from the Binjovi write integration never took its
authorization away.
The bootstrap
INSERTs the desired repository rowsWHERE NOT EXISTS, and theonly two
DELETEs in that transaction clean up the retiredbinjovi-operator-botobserver integrations. The statement is add-only. Arepository dropped from the list in Git kept its row in
authorized_integ_resource_repo, andbinjovi-botkept write authorization toit, indefinitely. Nothing reported that anywhere.
It also made the repository undeletable. Deleting
sean/hermesanswered 500,and the Forgejo log gave the reason:
Hermes hit both halves at once: a live write grant to a service that no longer
exists, and a row that blocked removing the repository at all.
The change
Adds the matching
DELETEso the bootstrap converges instead of onlyaccumulating. It reuses the same desired list the
INSERTuses, so the twocannot drift apart.
NOT INis safe here. Every id is already checked against^[1-9][0-9]{0,18}$in the guard loop before
psqlruns, so no NULL can enter the list, and thedegenerate
NOT INcase deletes nothing rather than everything.The Job template is immutable, so the generation moves v28 -> v29 and the
fingerprint pin moves with it.
Scope
Found while retiring Hermes, but it is not a Hermes problem -- it applies to
every repository ever dropped from that list. Worth checking whether any other
stale rows are already in the table.
bash tests/check.shexits 0.https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA
Removing a repository from the Binjovi write integration never took its authorization away. The bootstrap INSERTs the desired repository rows WHERE NOT EXISTS and the only two DELETEs in that transaction clean up the retired binjovi-operator-bot observer integrations, so the statement is add-only. A repository dropped from the list in Git kept its row in authorized_integ_resource_repo, and binjovi-bot kept write authorization to it. Nothing reported that. It also made the repository undeletable. Deleting sean/hermes answered 500, and Forgejo logged the reason: DeleteRepository: foreign key constraint violation: update or delete on table "repository" violates foreign key constraint "authorized_integ_resource_repo_repo_id_fkey" Hermes hit both halves: a live write grant to a retired service, and a row that blocked removing the repository at all. This adds the matching DELETE so the bootstrap converges instead of only accumulating. It reuses the same desired list, so the two cannot drift. NOT IN is safe here: every id is already checked against ^[1-9][0-9]{0,18}$ before psql runs, so no NULL can enter the list, and the degenerate case of NOT IN deletes nothing rather than everything. The Job template is immutable, so the generation moves to v29 and the fingerprint pin moves with it. Claude-Session: https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA