Q: Command Dispatcher Event Severity

[kbotteon]

If a command fails for any reason, like a Fw::CmdResponse::VALIDATION_ERROR, it is reported as an event with severity Command, which is highlighted in GDS in green. Implementation [Link] courtesy of @thomas-bc.

Is this intentional? It seems odd that an error would not stand out in the event log, and that at least a WARNING_LO would not be issued for a failure of any sort. Is there a preferred approach to direct Users' attention to failed commands?

[Joshua-Anderson]

I think the assumption may be that if a component returns a command failure it will also raise a warning EVR indicating why the command was failed.

Other projects I have worked with outside of fprime also do the same, where both command successes and failures are treated as command severity.

[kbotteon]

I see, so I guess the idea is that the command itself technically succeeded as it made it to the dispatcher and component. I'll do the same as you describe and add additional EVRs to send in addition to the validation error, etc.

[LeStarch]

Once upon a time, command errors were treated as WARNING. This may have been a regression that came in with FPP. @kbotteon @timcanham should command validation errors be WARNING and not COMMAND severity?

[timcanham]

IMHO they should be WARNING_HI, since it is an error condition.

[kbotteon]

My initial expectation was at least a WARNING_LO since it is a failure of some sort, as Tim points out. Perhaps not a HI since this kind of command failure is a user error, not an issue with the system.

[Joshua-Anderson]

Treating it as command severity has allowed other (non-fprime) projects to build command analysis tooling that grabs all the command severity EVRs - though I'm sure you could build the tooling other ways.

You can make reasonable cases for both sides. I think longer term we should have some discussion about the precise definition of EVR severities and making sure all the core fprime components are consistant. There's definitely some inconsistant applications of WARNING_HI vs WARNING_LO around the framework.