-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Locks unlimited in time have undefined behaviour #81
Comments
Note that the rust server has the same behaviour as the python one: both would allow unlimited locks but it is unreachable in both servers. EDIT: Here is the issue on the rust server IRL2/nanover-rs#216 |
Pinging @Ragzouken for an opinion. |
First instinct is that unlimited locks are a feature of As far as I can tell there aren't actually any tests for lock expiration for either The code for non-expiring locks is trivial to remove and later restore, so it wouldn't hurt to remove it if that seems sensible. Maybe in the future we would like to support client's creating non-expiring locks when we have the lifecycle stuff to expire them on client exit. Maybe locks is something that gets a full review when state lifecycle stuff comes around anyway. No strong opinion. |
I am happy to close the issue from this answer. I let you choose to close it or not, in case you'd like to keep it open for when you look at the life cycle. |
State locks have all the facilities to handle a lock without timeout (for instance here). Such a permanent lock would occur if the timeout is set to
None
, seenanover-protocol/python-libraries/nanover-core/src/nanover/state/state_service.py
Line 217 in 6b7f45b
None
as aNone
timeout in the lock update request would remove the lock (See the protocol definition and its implementation).Do we want to keep this behaviour in the code or match the protocol more closely? Keeping the code as is may allow a server to create unlimited locks, which may be desirable, but it could lead to unreachable code and cause devs to misinterpret the expected behaviour, which is bad.
The text was updated successfully, but these errors were encountered: