Skip to content
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

Folder view doesn't update after sync merge in background #1390

Open
artwyman opened this issue Dec 21, 2023 · 0 comments
Open

Folder view doesn't update after sync merge in background #1390

artwyman opened this issue Dec 21, 2023 · 0 comments
Labels

Comments

@artwyman
Copy link
Collaborator

artwyman commented Dec 21, 2023

This is a somewhat complicated scenario I encountered while testing a different feature. I've investigated deeply enough to prove that the bad behavior I'm seeing is based on the wrong UI state, rather than the wrong PCDCollection state, but I haven't managed to figure out why the UI isn't updating.

Here's the test scenario:

  • Use consumer-client to create 2 semaphore signature PCDs: "1" and "2"
  • Open 2 Zupass tabs both looking at the root folder.
  • In Tab 1, delete signature PCD 1
  • In Tab 2, delete signature PCD 2
  • The log in Tab 2 shows that a merge occurred, and both of the removed PCDs were kept (as expected). However the UI in Tab 2 still shows only 1 signature PCD. It updated after the removal, but not after the merge which brought back the PCD.
  • Wait a while for both tabs to perform a background sync. At that point, the UI will update and both tabs show both signature PCDs again.

Note that there are some spurious uploads after the initial merge caused by #1340. I'm not sure if that's related to why the UI eventually updates.

Below is a trace of the merge with some extra logging counting PCDs at various points, and counting the results of some appHooks in the UI. In this test case, before removals, my user has 864 PCDs (including the 2 signatures) and the root folder has 4 PCDS (including the 2 signatures). The surprising part is that after the download merge completes (resulting in 864 PCDs, 2 signatures), the UI re-renders with only 3 PCDs in the root folder. The next doSync() call again has all PCDs, but there's never another call to usePCDsInFolder until the next periodic poll occurs.

dispatch.ts:737 [ART_DBG] doSync: pcds 863 signatures 1
dispatch.ts:751 [SYNC] sync action: download
useSyncE2EEStorage.tsx:395 [SYNC] downloading e2ee storage
index.mjs:393 [FETCH] http://localhost:3002/sync/v3/load?blobKey=33a3e3d34260ce3f24d3681fdcd54468d4e4194f7cdab544c75d3006469942867cfaff7ecc67262ae7bc033416a148d7d5cb01fa06a61fbc4fa519caa6e37419&knownRevision=468 GET
useSyncE2EEStorage.tsx:454 [SYNC] revision conflict on download needs merge!
useSyncE2EEStorage.tsx:304 [SYNC] merged PCDS: {localOnly: 1, remoteOnly: 1, both: 862, final: 864}
useSyncE2EEStorage.tsx:348 [SYNC] no merge of subscriptions: hashes are identical
useSyncE2EEStorage.tsx:482 [SYNC] downloaded e2ee storage (revision 469)
dispatch.ts:766 [ART_DBG] downloaded: pcds 864 signatures 2
appHooks.ts:65 [ART_DBG] usePCDsInFolder 3
PCDCardList.tsx:49 [ART_DBG] PCDCardList 3
dispatch.ts:737 [ART_DBG] doSync: pcds 864 signatures 2

Oddly, download is a case where the PCDCollection is always replaced with a whole new object (not just mutating the existing one) so I'd expect React to have no trouble detecting the changes and rendering.

@artwyman artwyman added the bug label Dec 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant