ControlClient (score/launch_manager/src/control_client/src/control_client.h) currently only exposes ActivateRunTarget(). The underlying ControlClientImpl (control_client_impl.hpp) already implements two additional methods, plus a callback registration point, that any State Management implementation built on top of Launch Manager would need — but none of these are reachable from the public API:
InterruptibleFuture GetInitialMachineStateTransitionResult() — the result of the one-time Machine State Startup transition; needed by SM at boot to confirm Machine Startup succeeded before entering its own initial state (AUTOSAR AP kGetInitialMachineStateRequest).
Result GetExecutionError(const IdentifierHash& processGroup) — needed to retrieve why a Process Group entered an Undefined state, for Health-Monitor-driven recovery logic.
The ControlClientImpl constructor accepts std::function<void(const ExecutionErrorEvent&)> undefinedStateCallback, but the public ControlClient() noexcept constructor takes no arguments — there is currently no way for a caller to register for this callback at all.
Why this matters
An SM implementation on top of Launch Manager needs all three: confirming the machine's own Startup transition before entering its initial state, and receiving/querying PG failures to drive recovery. Both are blocked purely by API surface — the implementation already exists in ControlClientImpl.
Suggested change
Add thin public wrappers on ControlClient for GetInitialMachineStateTransitionResult() and GetExecutionError(), and either (a) accept an optional undefinedStateCallback in ControlClient's constructor mirroring ControlClientImpl, or (b) add a SetUndefinedStateCallback(...) method.
Happy to open a PR if the general direction is acceptable — wanted to check first since ControlClient is a Pimpl-wrapped, ABI-stability-sensitive AUTOSAR-defined interface, and there may be constraints (versioning, the per-process-singleton rule) I'm not aware of that affect API design here.
ControlClient (score/launch_manager/src/control_client/src/control_client.h) currently only exposes ActivateRunTarget(). The underlying ControlClientImpl (control_client_impl.hpp) already implements two additional methods, plus a callback registration point, that any State Management implementation built on top of Launch Manager would need — but none of these are reachable from the public API:
InterruptibleFuture GetInitialMachineStateTransitionResult() — the result of the one-time Machine State Startup transition; needed by SM at boot to confirm Machine Startup succeeded before entering its own initial state (AUTOSAR AP kGetInitialMachineStateRequest).
Result GetExecutionError(const IdentifierHash& processGroup) — needed to retrieve why a Process Group entered an Undefined state, for Health-Monitor-driven recovery logic.
The ControlClientImpl constructor accepts std::function<void(const ExecutionErrorEvent&)> undefinedStateCallback, but the public ControlClient() noexcept constructor takes no arguments — there is currently no way for a caller to register for this callback at all.
Why this matters
An SM implementation on top of Launch Manager needs all three: confirming the machine's own Startup transition before entering its initial state, and receiving/querying PG failures to drive recovery. Both are blocked purely by API surface — the implementation already exists in ControlClientImpl.
Suggested change
Add thin public wrappers on ControlClient for GetInitialMachineStateTransitionResult() and GetExecutionError(), and either (a) accept an optional undefinedStateCallback in ControlClient's constructor mirroring ControlClientImpl, or (b) add a SetUndefinedStateCallback(...) method.
Happy to open a PR if the general direction is acceptable — wanted to check first since ControlClient is a Pimpl-wrapped, ABI-stability-sensitive AUTOSAR-defined interface, and there may be constraints (versioning, the per-process-singleton rule) I'm not aware of that affect API design here.