[jkosanam]

Summary

doctl harness-runtime connections revoke accepts only the connection id, which the server assigns. A user who knows the actor has to run connections list --actor and copy the id first. Revoke now also takes --actor, looks up that actor's connection for the provider, and revokes it.
Jira: MARSOHS-2183

Scope

 connections revoke <connection-id>        → DeleteConnection(id)            (unchanged)
+connections revoke --actor <actor>        → ListConnections(actor), then:
+  exactly 1 connection for <actor>        → DeleteConnection(id), "Revoked connection <id> for <actor>"
+  0 connections                           → exit 1, "no <provider> connection found for actor <actor>"
+  2 or more                               → exit 1, lists the ids, "revoke one by id"
+connections revoke <id> --actor <actor>   → exit 1, "pass either a connection id or --actor, not both"

Blast radius

🟡 Services: doctl (harness-runtime connections revoke) · Customers: new opt-in --actor flag; revoke by id behaves as before.

Rollout

• Rollback: revert; the change ships with the next doctl release and holds no state.

Decisions

• With more than one connection for the actor, revoke refuses instead of picking one, so it can never revoke a connection the user did not mean. (connectionIDForActor)
• The lookup reads every page of the list and stops at the second match; one match on page 1 does not prove there is no other. After 50 full pages it refuses rather than decide on a partial read.
• Only list rows whose actor matches exactly are candidates, so a server filter that also returns alice-bot for alice cannot cause a wrong revoke.
• The lookup is in doctl: the API already filters connections by actor and deletes by id, so no server change is needed.

Evidence

New revoke tests (by actor, none, several, other actor's row, a second match on page 2, the page cap, id plus --actor, 501 on lookup) pass; go test ./commands/... ./do/... passes except TestRegistryLogin and TestRegistryLogout, which fail the same way on main. Not run: against a live environment.

[DO-rrao]

Right now, connectionIDForActor only reads the first page of results (PerPage: 100). Since the API is paginated, an actor with more than 100 connections might have exactly one result on the first page, with the rest appearing on subsequent pages. If that happens, the command will go ahead and revoke that first connection, which breaks the safety guarantee that it should refuse when there are multiple connections.

[jkosanam]

Fixed in 8af7f48: connectionIDForActor now reads every page and counts matches across all of them