Collapsing item on mobile not getting synced to web

Steps to reproduce

Collapse an item in the mobile app.

Expected result

The item to be collapsed when viewed from desktop web.

Actual result

The item is not collapsed on desktop. Even if I reopen the Android app, wait 10 seconds (hoping that this eventually gets synced), then refresh the desktop page, it still isn’t collapsed. The mobile and desktop views become out of sync, and I have to manually collapse the item on desktop in order for it to actually reflect on all devices.

I’ve seen this happen a few times before, but over the past week it’s been happening much more frequently than in the past. Given our previous conversations regarding item collapses not following the same “item change/move” sync path I understand that it’s not guaranteed to be synced when “Synced” is displayed, but I’ve kept the mobile app open for much longer after it says “synced” and the change is still not persisted.

Do you know if this is a recent regression or if something else has changed in the way that view mode changes (e.g. collapse) are synced from mobile?

It just happened to me again, and I think what I described before was wrong.

It looks like the change is being synced from mobile, but the desktop page will not sync down the changes, even if I use ctrl+s multiple times. But if I do a full refresh of the webpage it properly shows the item as collapsed.

So it seems that sometimes the desktop page will think it doesn’t have any changes to sync down even if an item is collapsed. When this occurred right now I should point out that my computer was asleep for a while, including when I collapsed the item on mobile, and then it wouldn’t properly sync the collapsed item after coming back online. Note that it did sync actual items, just not the collapsed view (the items were added, but uncollapsed).

I think the code path where view changes are pulled down should be investigated, as it seems this is where the issue is.

Will take a look and try to repro, thanks for the report!

So what I’m seeing right now is - if there’s no document “content” change, then there is no notification of any document changes, thus the desktop app will not attempt to sync, unless there’s local changes. Since collapsed states are considered optional, per user data, it only gets synced down to the desktop app when actual changes happens to the document.

In my testing, if you collapse an item on the web app, ctrl-s to force sync, go to the desktop app and ctrl-s to force sync on the same document, the collapse comes through. If on the web app, you collapse, then make a change (edit an item or move an item), then the collapse also gets synced down to the desktop app.

That’s interesting. It makes sense that the web app wouldn’t pull down the collapsed view by itself. But what was strange was that it was pulling down new items that were added after I had collapsed an existing item, but it still wasn’t displaying the existing item as collapsed. The bigger issue though was that ctrl+s didn’t even pull down the collapsed view and I had to perform a full page refresh to see it (from a UX perspective, ideally ctrl+s and page refresh would be equivalent).

I’m assuming there are different code paths for a full sync when you refresh (or open) the web app, versus using ctrl+s, for performance reasons. Could it be that the web app thinks it’s synchronized the user data, and so it doesn’t attempt to pull this down even when ctrl+s is manually invoked?

Unfortunately it is pretty rare, so I can’t reliably repro. If I see the issue again where the web app doesn’t reflect the collapsed view, even after ctrl+s, is there some diagnostic information I can collect and send over, perhaps from the console?

I see. That does sound like it shouldn’t happen.

If I understand correctly: When the issue happens, and you open a 2nd tab, you’ll see a different collapsed state, even after you force-sync the first tab. I can’t think of a reason why that would happen; the sync state is controlled by a per-user per-document version number that is incremented any time collapse state changes, and is checked when syncing.

As for debugging info, I’m not quite sure - the ideal case would be if you can identify a guaranteed way to repro. The only alternative I can think of would be to ask you to dump a bunch of network requests which would be helpful but still quite time consuming to comb through (some of it would be compressed data too).

To verify the collapsed state from collapsing an item on mobile (native Android app) was synced to the servers I opened Dynalist in Chrome on my phone and saw the proper state (same phone where I collapsed the item), but I didn’t view it in a 2nd tab on my PC.

I’ll try to come up with a reliable repro :slight_smile: Thanks for looking into this!

@Shida This just happened to me again, and I currently have Dynalist open in a browser tab that does not reflect the collapsed view even after repeated ctrl+s. Opening another tab on the same machine shows the item collapsed so it definitely is fully synced to the server.

Since my system is in this inconsistent state I’m trying a couple of experiments. I’ve tried collapsing a different item on mobile, and this one properly reflects on the web, even though the old one remains uncollapsed (implying it has recognized the document version has changed, but it just doesn’t sync down the state correctly for the problem item?). I’ve tried collapsing and uncollapsing the “problem item” multiple times, but it still doesn’t reflect as collapsed on the web.

However…if I add an item below the “problem item” it then reflected the item as collapsed on web!

I should note that in ALL instances where I’ve observed this issue the uncollapsed item is the last item in the list (indented one level under the document root). Specifically the hierarchy in the document looks like this:

- Foo
- Bar
- Baz
  + Problem Item (collapsed, with at least one item underneath)

My theory is that there is some off by one bug that can cause the item collapse state to become inconsistent for the last item in the document, under specific edge cases (not sure what the edge cases are though…). This could explain why placing an item below it would then force the item collapse state to be corrected, as it would no longer be the last item in the document.

After the web app recognizes the document version number has changed, how does it figure out what has changed? Is there a log of changes that have occurred in each document version that are replayed to reach the final state, or does it simply update its current state to the latest user data state (for the latest document version)?

I can think of one case where it could fail - If at the time of syncing, the item on the receiving client’s side doesn’t have any child item, then it fails to collapse. Later once the child items are added, it is not collapsed since it’s considered synced.

The only issue is - when syncing a document, the contents are synced first, then the collapsed states are applied. This means that case shouldn’t happen.

In either case, to answer your question, each node id is tagged with a version ID and it’s updated to a new version when a client changes the collapsed state. The sync protocol sends out a list of items for which the collapsed states have changed, and their resulting values (true/false). The version is per-user per-document, and is different from the document version because it’s different for each individual user.

As it still was inconsistent after uncollapsing/recollapsing repeatedly on the mobile side, I don’t think this could be the issue.

Is this server side pushed to each syncing client, or on the mobile client it sends out a list of items where the collapsed states have changed which then are replayed by the server to each syncing client?

If it’s server side, how does it determine which items it should send to the web client, does it internally track the synced node version ID for each connected session to identify which nodes differ and which updates to send? If so, if the client was offline for a while could this client session be cleared from the server side, leading to inconsistency?

If these updates are pushed from the mobile side, is it possible if I closed the app too quickly they weren’t sent out? Are these updates the only way that the server detects collapse state? If so then this argument doesn’t hold water as new clients showed the proper collapse state.

On the server side, we store the latest collapsed/expanded state and a version number that it was changed in. Each client holds its own “last synced version” which is presented to the server on sync. The server selects all collapse/expand states from the document that has version number strictly above the one presented and sends the list back to the client, as well as the current version number.

This “last synced version” is stored per item/node right? And this per-node version is sent to the server for all nodes in the document on every sync? Or are the version numbers of only a subset of nodes sent?

Also, is this version number specifically tied to collapse state changes, or is it a more general version number for the node?

No, only one “last synced version” is stored on the client per document. It’s only used for syncing collapsed changes, and it is different than the versioning/syncing structures used for syncing document content.

The last synced version for collapse state is sent to the server, and the server returns all nodes that have collapsed version numbers higher than the client’s last version, which is the subset of all nodes that had their collapsed state changed since last time the client had synced with the server.