Skip to content

wallet: Add injectable logger to WalletOptions for initialization diagnostics #8791

Description

@grypez

Sub-issue of #8790.

Problem

There is no visibility into the order or timing of controller initialization. This makes it impossible to observe empirically which messenger actions are called during init() vs. at runtime — information needed to make the init-messenger pattern decision tracked in #8790.

Proposed direction

Add an optional logger?: Pick<Console, 'info'> field to WalletOptions. When provided, initialize() should call logger.info([wallet] ${name}: initialized) immediately after each controller's init() call returns. The field should be no-op by default so library consumers are unaffected.

Passing console during development then gives a timestamped breadcrumb trail. Any messenger action call observed before a given controller's init-complete log is a candidate for an init messenger; calls observed after are runtime uses.

Acceptance

  • WalletOptions.logger is optional and defaults to no output.
  • initialize() emits [wallet] ${name}: initialized via logger?.info after each controller init completes.
  • Existing tests pass unchanged.
  • Passing { info: console.info } during a development run produces one log line per wired controller in initialization order.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions