Using Google Drive AppData to get around the limitations of chrome.storage.sync for sideloaded extensions is smart. Relying on a Google account instead of extension IDs makes sense for consistent data access. But how do you handle conflicts if multiple devices make changes at the same time? I was preparing for a system design round using prachub.com, and their question bank covered a lot of sync conflict scenarios that came up in my mock interview. If Drive integration had been part of that, it would probably have helped even more.
Great question! Concurrent edits are handled with last-write-wins semantics based on updatedAt timestamps ... whichever device flushes to Drive last wins for that instruction.
The one edge case worth knowing: if two devices edit the same instruction simultaneously, the losing write is gone with no notification. For a personal single-user tool this is acceptable, but it's a known limitation documented in the repo.
Deletes are safer ... a tombstone (deletedAt timestamp) wins over a live item when deletedAt > updatedAt, so a delete on device A can't be silently resurrected by a stale live copy on device B.
Full conflict resolution UI (diff + user choice) would be the natural next step if this ever needed multi-user support.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Using Google Drive AppData to get around the limitations of
chrome.storage.syncfor sideloaded extensions is smart. Relying on a Google account instead of extension IDs makes sense for consistent data access. But how do you handle conflicts if multiple devices make changes at the same time? I was preparing for a system design round using prachub.com, and their question bank covered a lot of sync conflict scenarios that came up in my mock interview. If Drive integration had been part of that, it would probably have helped even more.Great question! Concurrent edits are handled with last-write-wins semantics based on updatedAt timestamps ... whichever device flushes to Drive last wins for that instruction.
The one edge case worth knowing: if two devices edit the same instruction simultaneously, the losing write is gone with no notification. For a personal single-user tool this is acceptable, but it's a known limitation documented in the repo.
Deletes are safer ... a tombstone (deletedAt timestamp) wins over a live item when deletedAt > updatedAt, so a delete on device A can't be silently resurrected by a stale live copy on device B.
Full conflict resolution UI (diff + user choice) would be the natural next step if this ever needed multi-user support.