slimtoolkit/slim · error

sensor received unepxected command: %#+v

Error message

sensor received unepxected command: %#+v

What it means

runWithMonitor waits for the monitor to finish, then — if no stop was seen — expects the next command on the commands channel to be *command.StopMonitor. If the received command is of any other type (or the channel yields a different command), the type assertion fails and this error is returned. Note the typo 'unepxected' is in the message itself.

Source

Thrown at pkg/app/sensor/controlled/controlled.go:224

			default:
				log.Info("sensor: ignoring unknown or unexpected command => ", cmd)
			} // eof: type switch

		case err := <-mon.Errors():
			log.WithError(err).Warn("sensor: non-critical monitor error condition")
			s.exe.PubEvent(event.Error, monitor.NonCriticalError(err).Error())

		case <-ticker.C:
			s.exe.HookTargetAppRunning()
			log.Debug(".")
		} // eof: select
	}

	if !stopCommandReceived {
		// Monitor can finish before the stop command is received.
		// In such case, we have to await the explicit stop.
		if cmd, ok := (<-s.exe.Commands()).(*command.StopMonitor); !ok {
			return fmt.Errorf("sensor received unepxected command: %#+v", cmd)
		}
	}

	return s.processMonitoringResults(mon)
}

func (s *Sensor) processMonitoringResults(mon monitor.CompositeMonitor) error {
	// A bit of code duplication to avoid starting a goroutine
	// for error event handling - keeping the control flow
	// "single-threaded" keeps reasoning about the logic.
	for _, err := range mon.DrainErrors() {
		log.WithError(err).Warn("sensor: non-critical monitor error condition (drained)")
		s.exe.PubEvent(event.Error, monitor.NonCriticalError(err).Error())
	}

	log.Info("sensor: composite monitor is done, checking status...")

	report, err := mon.Status()

View on GitHub (pinned to 81940d17fa)

Solutions

1. Log the received command (%#+v in the error shows its type and fields) and fix the control side to always send StopMonitor
2. Make the state machine reject out-of-order commands before they reach the sensor
3. Widen the check to tolerate/ignore known-benign commands while awaiting StopMonitor

Example fix

// before
if cmd, ok := (<-s.exe.Commands()).(*command.StopMonitor); !ok {
	return fmt.Errorf("sensor received unepxected command: %#+v", cmd)
}
// after
switch cmd := (<-s.exe.Commands()).(type) {
case *command.StopMonitor:
	// proceed
case nil:
	return fmt.Errorf("sensor commands channel closed")
default:
	return fmt.Errorf("sensor received unexpected command: %#+v", cmd)
}

// control side: only send StopMonitor while a monitor is active
// assert state before sending:
// if sensorState != monitoring { return errors.New("no active monitor") }

func isStopMonitor(cmd interface{}) (*command.StopMonitor, bool) {
	c, ok := cmd.(*command.StopMonitor)
	return c, ok
}

if err := runSensor(); err != nil {
	if strings.Contains(err.Error(), "received unepxected command") {
		log.Printf("out-of-order control command; check sender state machine")
	}
}

When it happens

Trigger: During a monitored run, a command other than StopMonitor (e.g. StartMonitor, abort, or a nil/unknown command) arrives on s.exe.Commands() after the monitor finished.

Common situations: Control-plane sending commands in unexpected order, state machine races, duplicate start commands issued while a monitor is running.

Related errors

• sensor shutdown before monitor stop
• ambiguous start command: cannot use [app_name,app_args] and
• findSymlinks - could not convert fileInfo to Stat_t for %s
• failed to get system stat info for %s
• run sensor without monitor failed: %w

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