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

  1. Read the %+v dump in the error and compare cmd.GetName()/fields against the supported command types in the sensor.
  2. Upgrade or align the controller and sensor versions so both agree on the start-monitor command schema.
  3. Fix the caller that enqueues the command to emit the correct command type.
  4. 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

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


AI-assisted analysis of slimtoolkit/slim@81940d17fa (2026-08-31). Data as JSON: /api/errors/da7fe042df07d4eb. Report an issue: GitHub.