Attention is currently required from: pespin.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/37265?usp=email )
Change subject: sctp_proxy: fix no-op 'connecting' state timeout ......................................................................
Patch Set 1:
(2 comments)
File src/sctp_proxy.erl:
https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/37265/comment/fb883a69_31f18... PS1, Line 85: connecting(enter, OldState,
tip: I find it useful to prefix these state functions with "st_", this way it's clearer they are par […]
I can rename states, but in a separate patch. This patch is fixing a timer...
https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/37265/comment/0d662bda_29f34... PS1, Line 90: {next_state, connecting, S#{sock => Sock},
Reentering the state from withing the enter phase looks a bit werid to me tbh. I think it's totally fine and the proper thing to do to "keep_state" in here [...]
Looks like I did not emphasize this in the commit message clearly enough. I was under the same impression while writing this code, but as it turns out the `state_timeout` is ignored for `keep_state`. I did some experiments and found out that it only works for `next_state`, so this is why I am doing a loop state transition here. The API documentation confirms my discovery.
The problem I think is that in line 94 connecting_timeout, instead of shutting down you actually need to do "{next_state, connecting, ...}"
No. I do not implement the re-connection logic here, so I am just terminating the FSM. This is intentional and not really related to the problem of timeout never expiring (no mater what value I schedule, even very short ones).