Skip to content

fix: unlock update hasn't triggered after lock release #164

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

Merged
merged 4 commits into from
Sep 7, 2023

Conversation

ttypic
Copy link
Collaborator

@ttypic ttypic commented Sep 6, 2023

Unlock update hasn't triggered after lock release

Added emitting 'update' event after lock released


Update: I've updated this to a different fix. When you get a lock, it's not valuable to get unlocked locks - these are only useful in listeners. So the change here, which fixes the above bug, is to make sure we clear any unlocked locks, but send them in presence to process. After processing, the lock is clear. This makes the logic to compare if an event should be fired work (otherwise the mutated state is equal to the processed state and nothing happens locally).

@ttypic ttypic requested a review from dpiatek September 6, 2023 08:31
@dpiatek dpiatek removed their request for review September 7, 2023 13:33
Copy link
Collaborator Author

@ttypic ttypic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look good!

src/Locks.ts Outdated
lock.status = 'unlocked';
lock.reason = undefined;
// Send presence update with the updated lock, but delete afterwards so when the
// message is processed an update event is fired (the state of the )
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like part in parenthesis hasn't completed ( and looks like without it it's clear enough :) )

Dominik Piatek added 3 commits September 7, 2023 16:59
A lock release operation is not an error so it's confusing to have one as a reason when a lock is moved to `unlocked`. It's valid for a lock to change state and have an empty reason field for 2 main cases:
- a lock has become locked without issue
- a lock has becomne unlocked without issue
This ensure that if multiple connection state checks are in progress, each returns the same instance and does not create a new one.
@dpiatek dpiatek merged commit 4054de3 into main Sep 7, 2023
@dpiatek dpiatek deleted the fix-unlock-update branch September 7, 2023 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants