hero_auth: users_delete MCP tool does not actually delete users #40
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Bug
The
users_deleteMCP tool on hero_auth returns an empty JSON-RPC result{}but does not actually remove the user from the database.Steps to reproduce
tools/callwithusers_add(name: "crudtest", scope: "read")tools/callwithusers_list→ shows 2 userstools/callwithusers_delete(name: "crudtest") → returns{}tools/callwithusers_list→ still shows 2 usersExpected
After
users_delete, the user should be removed andusers_listshould show one fewer user.Verified on
herodev.gent04.grid.tf — tested via direct curl to
hero_auth_ui.sockMCP endpoint.Notes
The MCP transport is working correctly (request reaches backend, response returns). This is a hero_auth service-level bug in the delete handler.
mik-tf referenced this issue2026-03-18 20:13:52 +00:00
Fixed and verified on herodev (2026-03-18)
Root cause: The
users_deleteMCP/RPC tool requiredclient_id(UUID) but callers naturally passedname. Sinceargs.get("client_id")returned None, it returned an error instead of deleting.Fix: Both MCP and RPC handlers now accept
nameORclient_idfor user lookup. Updated OpenRPC spec and inline docs.Verification (CRUD round-trip on herodev):
users_list→ 0 usersusers_add(name: deltest)→ created with UUIDusers_delete(name: deltest)→{"deleted": "deltest"}✅users_list→ 0 users (confirmed deletion) ✅Commit (on
development):5dd8373— fix: users_delete now accepts name or client_idDeployed to herodev.
mik-tf referenced this issue2026-03-18 22:06:25 +00:00
mik-tf referenced this issue2026-03-18 22:37:34 +00:00
mik-tf referenced this issue2026-03-18 22:55:28 +00:00
mik-tf referenced this issue2026-03-18 22:58:45 +00:00
mik-tf referenced this issue2026-03-18 23:16:26 +00:00
mik-tf referenced this issue2026-03-18 23:28:29 +00:00
mik-tf referenced this issue2026-03-18 23:33:28 +00:00
mik-tf referenced this issue2026-03-19 00:26:50 +00:00