Project

General

Profile

Bug #5196

Verify several "event not permitted" log lines in unit tests

Added by pespin 3 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
07/12/2021
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

pespin ~/dev/sysmocom/git/osmo-msc $ ag "not permitted" tests/msc_vlr/ | grep Event
tests/msc_vlr/msc_vlr_test_gsm_authen.err:60:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:649:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1480:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1793:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2058:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2324:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:3242:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_ms_timeout.err:814:DMSC msc_a(IMSI-901700000004620:GERAN-A:LU){MSC_A_ST_WAIT_CLASSMARK_UPDATE}: Event MSC_A_EV_UNUSED not permitted

We should check whether those events are indeed not expected and only triggered by tests, or whether they can happen and hence we should allow them and handle them properly in the FSM.

Similar to:
https://gerrit.osmocom.org/c/osmo-msc/+/24916 msc_a.c: Allow MSC_A_EV_CN_CLOSE in state MSC_A_ST_RELEASING

History

#1 Updated by neels 3 months ago

My two cents: often I design the FSMs with the possibility in mind that some
events may arrive "out of sequence", like a trivial message received or a
sister FSM notification that doesn't matter anymore/yet in some FSM states.
Instead of weaving those into all the FSM states' permitted events and ignoring
them, i do sometimes simply not bother. Hence we get those "event not
permitted" logs, but no harm done really. Except confused users, which does
seem to happen more often than not. So it's not critical, but it would still be
good to remove that noise from the ERROR log.

Design wise I think it would be nice if osmo_fsm had a separate category for
ignored events per each state definition. That way we don't need to list
ignored events in every state action function, osmo_fsm would internally handle
aka ignore those. It would be immediately visible which events are really,
productively expected in a state, and which events are just there to silence
error messages. There could also be an allstate list of events to omit the "not
permitted" logging for, all across that FSM. (Maybe it would even suffice to
only have such an allstate list, instead of individual lists per state?)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)