Default session expiration may be unexpected to a regular user

[carpawell]

If session expiration is not specified, it is calculated. The way it is derived and the fact that it is not constant may confuse.

Current Behavior

I set 100ms block time and enabled sessions, however, did not specify session expiration. In the logs I saw

SessionExpirationTime is not set or wrong, setting default value

and thought that I was all right. However, it seems that the "default" is:

1. not a constant (you may disagree, but i think it should be stable in any run, this is how i understand default value for a config)
2. it does not make it if i specify smth shorter than a second:

   neo-go/pkg/services/rpcsrv/server.go

   Line 276 in 7304b2c

   conf.SessionExpirationTime = int(protoCfg.TimePerBlock / time.Second)

Expected Behavior

The default is smth like 30 seconds and does not depend on a block time. At least missing expiration time with enabled expirations, should not ever lead to a 0-second expiration (unusable sessions in fact).

Possible Solution

1. Make it const

or at least

2. Do not allow 0 duration in any cases

Steps to Reproduce

Specify 100ms time block and try to use sessions.

Context

100ms time block time test run.

Regression

Not sure.

Your Environment

v0.106.2

[AnnaShaleva]

In the logs I saw

There was also the value printed in the logs, that's the way how you can get a clue on the real value:

zap.Int("SessionExpirationTime", conf.SessionExpirationTime)

1. Make it const

Won't be done, it should be dependent from block time. Log message should be adjusted to change "setting default value" to something more user-friendly.

2. Do not allow 0 duration in any cases

Yes, this is a bug, should be fixed.

[carpawell]

Won't be done, it should be dependent from block time.

And you made it not in blocks but in seconds, huh? I do not have a strong opinion here but a session is a network thing to me so it should rely on some expectations about how fast a caller can do what he wants (and I am not sure reading some info from chain is connected to blocks or their duration).

[roman-khimov]

Sessions require snapshots, snapshots may affect block processing. 30s timeout with 15s is two blocks behind, but 300 blocks behind if you have 100ms blocks, a huge difference in terms of recency.

[carpawell]

Sessions require snapshots, snapshots may affect block processing

Oh, I see, why isn't it (config value) in blocks then?

[roman-khimov]

Mostly because that's the way C# node is configured. Users may also have some time-based preferences. But block-based default works fine.