slimtoolkit/slim · error
unexpected start monitor command: %+v
Error message
unexpected start monitor command: %+v
What it means
The standalone sensor's run loop received a StartMonitor command whose content it did not expect (wrong command type or malformed cmd payload), after publishing a StateCmdStartMonCmdWaiting event. The library throws this to abort processing of an unrecognized start-monitor command instead of proceeding with PrepareEnv. The %+v dump of cmd in the message shows exactly what was received.
Source
Thrown at pkg/app/sensor/standalone/standalone.go:118
func (s *Sensor) run() error {
raw := <-s.exe.Commands()
cmd, ok := (raw).(*command.StartMonitor)
if !ok {
log.
WithField("cmd", fmt.Sprintf("%+v", cmd)).
Error("sensor: unexpected start monitor command")
s.exe.HookMonitorFailed()
s.exe.PubEvent(event.StartMonitorFailed,
&event.StartMonitorFailedData{
Component: event.ComSensorCmdServer,
State: event.StateCmdStartMonCmdWaiting,
Context: map[string]string{
event.CtxCmdType: string(raw.GetName()),
},
})
return fmt.Errorf("unexpected start monitor command: %+v", cmd)
}
if err := s.artifactor.PrepareEnv(cmd); err != nil {
log.WithError(err).Error("sensor: artifactor.PrepareEnv() failed")
s.exe.HookMonitorFailed()
s.exe.PubEvent(event.StartMonitorFailed,
&event.StartMonitorFailedData{
Component: event.ComSensorCmdServer,
State: event.StateEnvPreparing,
Errors: []string{err.Error()},
})
return fmt.Errorf("failed to prepare artifacts env: %w", err)
}
origPaths, err := s.artifactor.GetCurrentPaths(s.mountPoint, cmd.Excludes)
if err != nil {
log.WithError(err).Error("sensor: artifactor.GetCurrentPaths() failed")
return fmt.Errorf("failed to enumerate current paths: %w", err)View on GitHub (pinned to 81940d17fa)
Solutions
- Read the %+v dump in the error and compare cmd.GetName()/fields against the supported command types in the sensor.
- Upgrade or align the controller and sensor versions so both agree on the start-monitor command schema.
- Fix the caller that enqueues the command to emit the correct command type.
- If reproducing in tests, construct the command using the sensor's own command constructors instead of raw values.
Example fix
// before
// controller sends an ad-hoc command type
raw := command.New("start-mon", payload) // unknown to sensor
// after
raw := command.New(command.TypeStartMonitor, payload) // use supported type Defensive patterns
Strategy: validation
Validate before calling
switch raw.GetName() {
case command.TypeStartMonitor:
// supported
default:
return fmt.Errorf("controller bug: unsupported command %q", raw.GetName())
} Try / catch
if err := sensor.Run(ctx); err != nil {
var unexpectedCmd interface{ Error() string }
if strings.Contains(err.Error(), "unexpected start monitor command") {
log.Errorf("protocol mismatch, payload: %s", err.Error())
}
return err
} Prevention
- Keep controller and sensor on the same version so command schemas match.
- Only construct commands via the shared command package constructors.
- Log raw.GetName() on receipt to catch protocol drift early.
- Add a contract test asserting the emitted command type is recognized by the sensor.
When it happens
Trigger: The control server sends a raw command whose GetName() does not match a supported start-monitor command type, so the switch/state-machine in run() falls through to the error return with the unexpected cmd struct.
Common situations: Version mismatch between the controller/orchestrator sending commands and the sensor binary; a corrupted or hand-crafted control payload; wiring the wrong command type through the cmd server during development.
Related errors
- sensor shutdown before monitor stop
- ambiguous start command: cannot use [app_name,app_args] and
- run sensor without monitor failed: %w
- run sensor with monitor failed: %w
- failed to prepare artifacts env: %w
AI-assisted analysis of slimtoolkit/slim@81940d17fa (2026-08-31).
Data as JSON: /api/errors/da7fe042df07d4eb.
Report an issue: GitHub.