fix: Resolve errors, omissions, duplicates in Engine types Global{Actions,Events}

[MajorLift]

Description

The GlobalActions and GlobalEvents types have not been updated to keep up with the controller V2 upgrades. This commit adds missing entries and fixes redundant, outdated, or erroneous entries.

All changes in this commit are purely at the type-level with no impact on runtime behavior.

Related issues

• Follow-up to controller V2 upgrades: https://github.com/MetaMask/MetaMask-planning/issues/3234
• Blocks chore(deps): Bump @metamask/composable-controller from ^3.0.0 to ^10.0.0 #10441

Manual testing steps

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: 5b79f71
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/cdab6387-eff2-4a65-83d7-9d6ee48697e8

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[github-actions]

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: 508dc9a
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/4c3a06f1-5297-42d3-99c8-414200b9f814

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[github-actions]

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: f18f117
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/59052ee7-6a1f-4761-ac56-8701882f433d

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[MajorLift]

Fixes errors with notifications controllers action types.

[mcmire]

@MajorLift How did we know that these types were incorrect before and how do we know that they are correct now? Or, better, is there any way to guarantee that this won't happen again?

[github-actions]

Bitrise

✅✅✅ pr_smoke_e2e_pipeline passed on Bitrise! ✅✅✅

Commit hash: e31fa74
Build link: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/0722b2bd-3b5d-43d0-b90e-1735b36b05f5

Note

• You can kick off another pr_smoke_e2e_pipeline on Bitrise by removing and re-applying the Run Smoke E2E label on the pull request

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[MajorLift]

@mcmire The only place the Global{Actions,Events} types are used is in the ControllerMessenger type definition.

And these are the expectations for the Actions, Events generic type parameters of ControllerMessenger:

• The internal actions/events of all controllers in the engine context are available to the engine's messenger.
• Conversely, the engine's context contains all controllers required to implement the allowed actions/events specified by the controllers in the engine context.

So in this PR I've simply updated the Global{Actions,Events} types to include all internal actions/events of every V2 controller in the engine context (which is now all of them).

As to how we can keep these up-to-date in the future:

If the GlobalActions or GlobalEvents type is incomplete, or if an invalid entry is added to a restricted messenger's allowlist, we get the following error message:

Type '"ExampleController:exampleAction"' is not assignable to type '"AddressBookController:getState" | "ApprovalController:getState" | "ApprovalController:clearRequests" | "ApprovalController:addRequest" | "ApprovalController:hasRequest" | ... 132 more ... | "AssetsContractController:getERC1155TokenURI"'. Did you mean '"ExampleController:otherAction"'?ts(2820)

A simpler sanity test is instantiating the engine's messenger as ControllerMessenger<never, never>. We get Type 'string' is not assignable to type 'never'.ts(2322) errors in the actions/events allowlist of every restricted messenger instantiation in the Engine class.

[mcmire]

If the GlobalActions or GlobalEvents type is incomplete, or if an invalid entry is added to a restricted messenger's allowlist, we get the following error message:

This makes sense! I guess I am curious why the global actions/events list fell so far out of sync though. Are we getting type errors on main now which are being somehow suppressed? I worry that it will fall out of sync again in the future and we or someone will have to spend time manually going through and cross-checking them.

[MajorLift]

Global{Actions,Events} have probably been updated to resolve any errors in main. But the ComposableController update branch #10441 showed a lot of errors, because the stateChange event for all controllers needs to be included to its events allowlist, but many corresponding ControllerEvents types were missing from GlobalEvents.

I think that with the updates in this PR, the only scenario where this becomes relevant in the future is when adding new controllers to engine context. Whoever's doing that will need to know to update Global{Actions,Events} and the allowedEvents constructor option of ComposableController (EngineService will no longer need to be updated manually with this change).

[mcmire]

LGTM.

[Gudahtt]

LGTM!

[Cal-L]

Lgtm