What happens #
In /login, ctrl+d on an account that a profile still pins asks to remove it, and then the account row disappears. Leave /login, open it again, and the account is back.
The daemon is right here: DELETE /auth/accounts/<id> answers 409 account_in_use while a profile pins the key, and GET /auth keeps listing it. The client draws that refusal as a successful removal.
Steps #
- In
/login, make a key account (OpenCode Go, for example) and a profile that uses it. ctrl+don the account row, then enter to confirm.- The accounts section empties, and the footer says "Provider account is referenced by a saved profile."
- Esc out of
/loginand open it again: the account is listed again, unchanged.
Why #
reloadCmdreturnedsignInsLoadedMsgwith no listing when the change failed.- The
signInsLoadedMsghandler assignedmsg.Listed.Accountsunconditionally, so a message with no listing cleared the rows and the picker redrew empty. - Reopening reads the daemon, which still has the account, so the row returns.
The 409 itself is correct: a pinned account must not be removed. What is wrong is that the screen shows it as gone, and that ctrl+d asks a question whose answer is already no.
Fix #
Commit dcd45da8 on tui/login-refused-removal (local so far, same author as this issue):
- reload after a refused change too, so the rows show what the daemon holds
- a read that fails keeps the rows it has (
LoadedonsignInsLoadedMsg); no listing is not an empty listing ctrl+don a pinned account says "still used by ; give it another key first (ctrl+e)" instead of opening the confirm- a successful change clears the stale status line
cli/internal/tui/login_test.gocovers the refused removal, the pinned refusal and a failed read; new gallery statelogin/account-pinned;robot-docs/tui.mdupdated
Seen on main at ff9d6dc0. go -C cli vet ./... and go -C cli test ./internal/tui pass; ./test.sh was not run in this environment (no nix), and two Go e2e tests unrelated to this change fail on a clean tree here too.
Fixed in e13a5262: a refused or failed change keeps the rows (no listing is not an empty listing; a failed settings read no longer wipes profiles either), the list is re-read after a refusal, and ctrl+d on an account a profile pins (or a rotation's last account) says which profiles use it and to move them with ctrl+e instead of opening a confirm; a 409 refusal names the profile too. Tests: login_test.go and e2e TestTUILoginRefusedRemovalKeepsThePinnedAccount.