figma-plugin: Updated time verified not working while using Genreic Version Storage/JSONBIN

Describe the bug When using this plug-in for multi-person collaboration, I noticed that the plug-in does not remind us that there are conflicts in our changes. Even if the local data is older than the remote data, it can always be submitted and overwritten. In the end, we tested and determined that the logic of comparing local and remote update timestamps in the plugin source code did not work.

To Reproduce Steps to reproduce the behavior:

1. Use JSONBin or Genreic Version Storage as sync method, People A & People B use same key.
2. People A update his design token (Update on changes clicked)
3. People B update his design token without syncing
4. People A sync.

Expected behavior People B should see warning like this:

Screenshots or Screencasts In fact, B updated successfully like this: and A found that his update overwritten.

Figma file (optional) Any Figma

JSON (optional) Any JSON

Point After checking source code we find:

rootState.uiState.lastUpdatedAt (tokenState.updateDocument) 
-> lastUpdatedAt (updateTokensOnSources) 
-> lastUpdatedAt  (updateRemoteTokens) 
-> oldUpdatedAt (updateGenericVersionedTokens)
-> compareUpdatedAt

It seems that rootUI.state.lastUpdatedAt never update after initialized as null, and rootState.uiState.lastUpdatedAt ?? new Date().toISOString() always go to fallback logic.

Other bugs

1. Auto update never triggered since REMOVING/RENAMING tokens.
2. Close the plugin then reopen it, sync connection losed, need to be reactived by update settings.
3. PUT Request failed (404/500/400) without any notification while using Genreic Version Storage.

Suggestions

1. Use data version instead of data updatedAt may be better, and ‘version/updatedAt’ need to be shown at plugin panel.
2. notifyToUI should be triggered when any request failed, and its content should contain response.message.
3. GET request before PUT during retrieval need to be diffrenet from normal GET request (by send local updatedAt timestamp for server checking or other resolutions), because the first one may block the subsequent process, while second one always do sync logic successfully.