Skip to content

Disable deleted sub-account addresses; reinstate and pool them on create - #49

Merged
markmnl merged 1 commit into
mainfrom
linked-address-lifecycle
Oct 10, 2026
Merged

markmnl merged 1 commit into
mainfrom
linked-address-lifecycle

Conversation

@markmnl

@markmnl markmnl commented Oct 10, 2026

Copy link
Copy Markdown
Owner

Summary

Needs markmnl/fmsgid#7 (accepting_new / quota_pool on POST /fmsgid, {"created","reinstated"} response).

  • DELETE /fmsg/sub-accounts/:agent: for a derived_sub_account grant, first POST /fmsgid {"address":…, "accepting_new":false} so fmsg hosts refuse new mail to the address (they answer "not accepting"), then delete the grant. Fail-closed: if fmsgid fails (or is too old to support accepting_new, detected by its empty response body) the request is 503 and the grant is kept so the owner can retry. Deleting first would leave the address accepting mail with no grant left to retry the disable from. Delegated identities are not touched.
  • POST /fmsg/sub-accounts: registers the derived address with accepting_new: true and quota_pool: <owner> (shares the owner's quota). Only the owner can derive @<owner>_<agent>@<domain>, so an existing address is theirs from before: fmsgid reinstates it and the response gains "reinstated": true (false for a new address) so a UI can say the address was used before, is active again and its earlier messages are still there. If the grant can't be created afterwards (409, limit), a reinstated address is disabled again.
  • api-key create CLI: same registration/reinstatement/undo; prints reinstated=true|false. (There is no CLI delete.)
  • fmsgid lookup cache entry is dropped after every POST /fmsgid, so a disabled address is refused immediately.
  • With an older fmsgid, creation works as before (reinstated: false); deletion fails with 503 until fmsgid is upgraded.

Test plan

  • go test -race ./..., go vet ./..., gofmt clean
  • With FMSG_TEST_DATABASE_URL (throwaway Postgres 17): handler lifecycle (create → delete disables → re-create reinstates, quota_pool = owner; conflict leaves it accepting), delete keeps the grant on fmsgid failure / old fmsgid and succeeds on retry, delegated delete sends nothing, failed re-create (limit) re-disables, old fmsgid create; CLI reinstate and undo-on-conflict
  • Middleware unit tests: payloads, reinstated parsing, empty/malformed/422/503 responses, cache invalidation

🤖 Generated with Claude Code

Deleting a derived sub-account now stops its address accepting new
messages in fmsgid (POST /fmsgid with accepting_new false), so fmsg
hosts refuse new mail to it, before the grant is deleted. If fmsgid
can't be updated the delete fails with 503 and keeps the grant, so it
can be retried rather than leaving an address accepting mail with
nothing to retry from. Delegated identities are left alone.

Creating a derived sub-account registers its address with
accepting_new true and quota_pool set to the owner, so it shares the
owner's quota. Only the owner can derive the address, so one that
already exists was theirs before: fmsgid reinstates it and the create
response reports "reinstated": true (false for a new address). If the
grant then can't be created the reinstated address is disabled again.
The api-key create CLI does the same and prints reinstated=.

An fmsgid without accepting_new answers POST /fmsgid with no body:
creation then works as before with reinstated false, and deletion
fails rather than claiming the address was disabled.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@markmnl
markmnl merged commit b7d16aa into main Oct 10, 2026
1 check passed
@markmnl
markmnl deleted the linked-address-lifecycle branch October 10, 2026 06:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant