starred/floccus

Fork 0

mirror of https://github.com/floccusaddon/floccus.git synced 2026-04-25 22:26:06 +03:00

[GH-ISSUE #1068] Waiting for a lock to time out on mobile is frustrating #709

New issue

Closed

opened 2026-02-25 22:37:53 +03:00 by kerem · 8 comments

kerem commented

2026-02-25 22:37:53 +03:00

Owner

Originally created by @marcelklehr on GitHub (Mar 8, 2022).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1068

Describe the feature you'd like to request

Sometimes floccus waits for a lock. While not an issue on Desktop, on mobile this can become a problem as users expect to be able to use the app when opening it.

Describe the solution you'd like

Allow users to force override the lock via the tap of a button.

Describe alternatives you've considered

Allow sync to run in background.

Originally created by @marcelklehr on GitHub (Mar 8, 2022). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1068 ### Describe the feature you'd like to request Sometimes floccus waits for a lock. While not an issue on Desktop, on mobile this can become a problem as users expect to be able to use the app when opening it. ### Describe the solution you'd like Allow users to force override the lock via the tap of a button. ### Describe alternatives you've considered Allow sync to run in background.

kerem

2026-02-25 22:37:53 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-25 22:37:54 +03:00

Author

Owner

@raslop commented on GitHub (Mar 22, 2022):

Suggestion: The lock should contain information which device is currently holding the lock and since when, so that the user can check if this device is really still holding the lock for synchronization or not.

@raslop commented on GitHub (Mar 22, 2022): Suggestion: The lock should contain information which device is currently holding the lock and since when, so that the user can check if this device is really still holding the lock for synchronization or not.

kerem commented

2026-02-25 22:37:54 +03:00

Author

Owner

@marcelklehr commented on GitHub (Mar 23, 2022):

I'd rather avoid manual approaches like this, tbh. My new approach is for locks to contain a time stamp which is constantly updated while syncing. Feel free to let me know what you think :)

@marcelklehr commented on GitHub (Mar 23, 2022): I'd rather avoid manual approaches like this, tbh. My new approach is for locks to contain a time stamp which is constantly updated while syncing. Feel free to let me know what you think :)

kerem commented

2026-02-25 22:37:54 +03:00

Author

Owner

@raslop commented on GitHub (Mar 23, 2022):

I'd rather avoid manual approaches like this, tbh.

Hmm, I thought this issue is about a manual approach.
However, in general I agree that anything that can be safely automated should be automated.

I think we agree, that a lock must not be overridden as long as some other instance is still synchronizing. Overriding a lock of a "dead" device (i.e. one that was shutdown during synchronization without the possibility to release the lock or similar) is of course no problem (in my opinion).

However, if this issue is indeed about force overriding a lock on some device, than the device that currently holds the lock and is still synchronizing (i.e. not "dead") must abort its synchronization, right? Maybe it also has to restore some state that has been changed since the start of the synchronization (I don't know enough about the actual synchronization mechanisms).
At least some energy (CPU time, network bandwidth, etc.) on the still synchronization device is wasted (some ~5 year old laptop of mine needs up to ~25 minutes for synchronization sometimes), so it should at least be made clear to the user what consequences this force override may have.

My new approach is for locks to contain a time stamp which is constantly updated while syncing. Feel free to let me know what you think :)

That sounds indeed like an interesting idea and I believe this can work.
Some considerations:

I hope with "constantly updated timestamp" you not mean every second or so, but say every minute. Because each such update induces network traffic (which might not be cheap, especially on mobile devices) and a write operation on the server (I'm thinking about unnecessary writes on flash-based filesystems).
The case that the synchronizing device (that holds the lock) fails to update the lock-timestamp for some time (e.g. due to temporary network errors) must be handled properly. Probably by aborting the synchronization, because it cannot be sure that some other device now holds the lock.

@raslop commented on GitHub (Mar 23, 2022): >I'd rather avoid manual approaches like this, tbh. Hmm, I thought this issue is about a manual approach. However, in general I agree that anything that can be safely automated should be automated. I think we agree, that a lock must not be overridden as long as some other instance is still synchronizing. Overriding a lock of a "dead" device (i.e. one that was shutdown during synchronization without the possibility to release the lock or similar) is of course no problem (in my opinion). However, if this issue is indeed about force overriding a lock on some device, than the device that currently holds the lock and is still synchronizing (i.e. not "dead") must abort its synchronization, right? Maybe it also has to restore some state that has been changed since the start of the synchronization (I don't know enough about the actual synchronization mechanisms). At least some energy (CPU time, network bandwidth, etc.) on the still synchronization device is wasted (some ~5 year old laptop of mine needs up to ~25 minutes for synchronization sometimes), so it should at least be made clear to the user what consequences this force override may have. >My new approach is for locks to contain a time stamp which is constantly updated while syncing. Feel free to let me know what you think :) That sounds indeed like an interesting idea and I believe this can work. Some considerations: - I hope with "constantly updated timestamp" you not mean every second or so, but say every minute. Because each such update induces network traffic (which might not be cheap, especially on mobile devices) and a write operation on the server (I'm thinking about unnecessary writes on flash-based filesystems). - The case that the synchronizing device (that holds the lock) fails to update the lock-timestamp for some time (e.g. due to temporary network errors) must be handled properly. Probably by aborting the synchronization, because it cannot be sure that some other device now holds the lock.

kerem commented

2026-02-25 22:37:54 +03:00

Author

Owner

@mnalis commented on GitHub (Mar 23, 2022):

I think we agree, that a lock must not be overridden as long as some other instance is still synchronizing. Overriding a lock of a "dead" device (i.e. one that was shutdown during synchronization without the possibility to release the lock or similar) is of course no problem (in my opinion).

Note that there might be race conditions there, e.g. laptop was synchronizing and then in the middle of the sync automatically suspended due to low battery or inactivity or whatever. Other computer comes 15 minutes later and breaks the lock (that seems inactive) and does its sync. But some time after that laptop that was suspended comes back online and continues its sync that was halted in the middle and wreaks havoc to the bookmarks storage.

That should probably be detected and handled somehow (maybe the floccus should keep internal timestamp of last write operation, and verify it agains current clock before each write operation, and abort the sync if the last write operation was more that say 10minutes before [lock break timeout of 15 minutes minus some safety buffer]). That would make sure that current sync is aborted in case there is a chance someone else has broken the lock in the meantime.

@mnalis commented on GitHub (Mar 23, 2022): > I think we agree, that a lock must not be overridden as long as some other instance is still synchronizing. Overriding a lock of a "dead" device (i.e. one that was shutdown during synchronization without the possibility to release the lock or similar) is of course no problem (in my opinion). Note that there **might be race conditions there**, e.g. laptop was synchronizing and then in the middle of the sync automatically suspended due to low battery or inactivity or whatever. Other computer comes 15 minutes later and breaks the lock (that seems inactive) and does its sync. But some time after that laptop that was suspended comes back online and continues its sync that was halted in the middle and wreaks havoc to the bookmarks storage. That should probably be detected and handled somehow (maybe the floccus should keep internal timestamp of last write operation, and verify it agains current clock _**before each write operation**_, and abort the sync if the last write operation was more that say 10minutes before [lock break timeout of 15 minutes minus some safety buffer]). That would make sure that current sync is aborted in case there is a chance someone else has broken the lock in the meantime.

kerem commented

2026-02-25 22:37:54 +03:00

Author

Owner

@marcelklehr commented on GitHub (Mar 24, 2022):

That should probably be detected and handled somehow (maybe the floccus should keep internal timestamp of last write operation, and verify it agains current clock before each write operation, and abort the sync if the last write operation was more that say 10minutes before [lock break timeout of 15 minutes minus some safety buffer]). That would make sure that current sync is aborted in case there is a chance someone else has broken the lock in the meantime.

Good point! I'll try to implement this.

@marcelklehr commented on GitHub (Mar 24, 2022): > That should probably be detected and handled somehow (maybe the floccus should keep internal timestamp of last write operation, and verify it agains current clock before each write operation, and abort the sync if the last write operation was more that say 10minutes before [lock break timeout of 15 minutes minus some safety buffer]). That would make sure that current sync is aborted in case there is a chance someone else has broken the lock in the meantime. Good point! I'll try to implement this.

kerem commented

2026-02-25 22:37:54 +03:00

Author

Owner

@marcelklehr commented on GitHub (Mar 24, 2022):

The case that the synchronizing device (that holds the lock) fails to update the lock-timestamp for some time

That's a nice point as well!

@marcelklehr commented on GitHub (Mar 24, 2022): > The case that the synchronizing device (that holds the lock) fails to update the lock-timestamp for some time That's a nice point as well!

kerem commented

2026-02-25 22:37:54 +03:00

Author

Owner

@marcelklehr commented on GitHub (Mar 24, 2022):

The issue is less about the solution but more abou the problem of waiting for a lock to be free

Sometimes floccus waits for a lock. While not an issue on Desktop, on mobile this can become a problem as users expect to be able to use the app when opening it.

@marcelklehr commented on GitHub (Mar 24, 2022): The issue is less about the solution but more abou the problem of waiting for a lock to be free > Sometimes floccus waits for a lock. While not an issue on Desktop, on mobile this can become a problem as users expect to be able to use the app when opening it.

kerem commented

2026-02-25 22:37:54 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 21, 2024):

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions[bot] commented on GitHub (Dec 21, 2024): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/floccus#709

No description provided.

Rows
Columns