Skip to content

feat(messenger): add getRegisteredActionTypes accessor#9271

Open
sirtimid wants to merge 1 commit into
mainfrom
sirtimid/messenger-registered-action-types
Open

feat(messenger): add getRegisteredActionTypes accessor#9271
sirtimid wants to merge 1 commit into
mainfrom
sirtimid/messenger-registered-action-types

Conversation

@sirtimid

@sirtimid sirtimid commented Jun 25, 2026

Copy link
Copy Markdown
Member

Explanation

Adds a public, read-only accessor Messenger.getRegisteredActionTypes() that returns the action types a messenger can call() directly — actions registered on it plus actions delegated into it from a child messenger. It returns [...this.#actions.keys()].

There is no public way to enumerate a messenger's callable actions today.

Why string[] and not Action['type'][]

The first instinct is to type the return as the messenger's action-type union for nicer caller types. That's not safe here: it would make Action appear in a covariant (return) position — the first such member on the class. Every existing Action-dependent method (call, registerActionHandler) deliberately keeps Action behind a bounded generic to avoid this. A covariant Action member breaks assigning a messenger to a narrower-typed one (e.g. passing a controller's full messenger to a service typed against only a subset of its actions) — a pattern consumers rely on (@metamask/perps-controller does exactly this and fails to compile with the union return). No union-derived return type avoids this; only a constant return type does. string[] is sufficient for the consumer below, which just lists/prints the types.

Why

@metamask/wallet-cli is gaining an mm daemon list command to enumerate the actions on the wallet's root messenger (sibling to the existing mm daemon call <Controller>:<method>). That needs a public accessor on the messenger, which this PR adds. The command itself is a separate wallet-cli follow-up.

Notes for reviewers

  • Non-breaking and purely additive — new read-only method, no behavior change. Verified with a full monorepo build.
  • Method name is open to bikeshedding.

🤖 Generated with Claude Code


Note

Low Risk
Purely additive read-only introspection with no changes to registration, delegation, or call behavior.

Overview
Adds a read-only Messenger.getRegisteredActionTypes() API that lists every action type the instance can invoke via call()—handlers on that messenger plus actions delegated into it, and not actions delegated away.

The implementation snapshots keys from the internal #actions map (same source getAction / call use), so unregistering or revoking delegation updates the list. Tests cover empty messengers, register/unregister, and delegated-in actions; the unreleased changelog documents the method for tooling such as wallet CLI action listing.

Reviewed by Cursor Bugbot for commit c14f260. Bugbot is set up for automated code reviews on this repo. Configure here.

@sirtimid sirtimid force-pushed the sirtimid/messenger-registered-action-types branch from ad9e23f to 41944f4 Compare June 25, 2026 20:34
@sirtimid sirtimid marked this pull request as ready for review June 25, 2026 20:35
@sirtimid sirtimid requested a review from a team as a code owner June 25, 2026 20:35
@sirtimid sirtimid temporarily deployed to default-branch June 25, 2026 20:35 — with GitHub Actions Inactive
Add a public, read-only `getRegisteredActionTypes()` method to the
`Messenger` class that returns every action type the messenger can call
directly — actions registered on it plus actions delegated into it. This
gives consumers a way to discover a messenger's callable action surface
(needed by an upcoming `mm daemon list` command in `@metamask/wallet-cli`).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@sirtimid sirtimid force-pushed the sirtimid/messenger-registered-action-types branch from 41944f4 to c14f260 Compare June 25, 2026 20:57
@sirtimid sirtimid enabled auto-merge June 25, 2026 20:59
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