Collapsing item on mobile not getting synced to web

[Shida]

Yeah the version handing is all server sided. Will think of a better solution in the coming days!

[Shida]

Will be fixed in the upcoming release on web, with mobile release coming a bit later!

[Alan]

I’m wondering what the rule is here. Is it that there is ONE collapsed state for a node, irrespective of who looks at it?

[Shida]

It’s stored on the server side as a per-user/per-document blob, which contains all the node’s collapsed state.

[Alan]

Per user but not per device? Okay. Just wondering.

[Shida]

It should be synced across devices, at least on web. Desktop might work a bit different.

[Jayden_Navarro]

@Shida Have any changes gone out related to this already? I noticed something odd today on mobile I’ve never seen before (even if mobile code hasn’t changed, maybe affected by server side logic change). I had an item with no children, and I’m sure that my mobile client was up to date. I added two child items using Quick Dynalist (API), and when I reopened the android app the item was collapsed. This shouldn’t happen since the item was childless (therefore uncollapsed), and then new child items were added. Could recent changes have caused this unexpected behavior?

[Jayden_Navarro]

It definitely looks like this change has started rolling out as the first repro I gave is fixed (thanks for that!). Although I’m seeing some other weird behavior now, likely due to these changes:

On web:

1. Create item with one child and collapse.
2. Zoom into item and delete the child.
3. Zoom out (item will not have any children, so is uncollapsed).
4. Zoom into the item again and add a child.
5. Zoom out, and observe that the item is collapsed again.

NOTE: If on step 4 you add the child while zoomed out it will properly be uncollapsed. It’s only an issue when you add the child while zoomed in to the parent item.

[Jayden_Navarro]

I also have a new repro (slightly different than the original one, but in a similar vein) that shows that this isn’t fixed.

On the web:

1. Create item with one child and collapse (Foo -> Bar).
2. Go offline (dev tools -> network).
3. Zoom in and delete the child item.
4. Zoom out and add a new child item “Baz”. The item will be uncollapsed.
5. In a new tab, zoom into the item and add a second item “Qux”.
6. Reconnect the first client and sync up.
7. Verify the reconnected client is uncollapsed, while all other clients are still collapsed (even though all clients do show the proper child items “Baz” and “Qux”).

I’m guessing that in this recent update there’s some tentatively_collapsed state that’s kept for nodes with deleted children that haven’t synced up yet, is that correct? But when you add a new child item zoomed out the client “knows” that it is no longer collapsed, leading us back to the original bug. This type of logic likely also explains the other issue I reported one post above.

In this case I actually think it makes more sense for the server-side state to be “uncollapsed” if we’re following a “last-write-wins” model. This is made trickier by the fact that we don’t want to uncollapse items if they only became empty (no new children added), like in the original repro.

Here’s an idea for what might fix this: For each node that experiences a collapse state change keep track of the following (clearing out this state after a sync occurs):

1. The last synced collapse state for the node.
2. The current collapse state for the node (e.g. if you explicitly uncollapsed the item OR deleted all children, it is uncollapsed).
3. Whether the collapse state change is tentative or definite. An explicit collapse/uncollapse is a definite change, whereas an item becoming uncollapsed due to all children being deleted is tentative. Adding the first child to an item is also a definite change (since the item is now visibly uncollapsed).

If a change is tentative, after a sync it should apply the following state changes (in this order of precedence):

1. Any new collapse state changes synced down for that node.
2. The last synced collapse state for the node.

If a change is definite, it should override any collapse state changes it sees and sync up its collapse state to the server (last-write-wins).

(this also relies on the server side explicitly setting nodes without any children as “uncollapsed”, including bumping the user version number when this occurs. I think this was the old behavior, but after the update this seems to have changed.)

It looks like the current solution is doing something like 1 and 2, but maybe it’s missing the 3rd part?

If we follow this new model, then the above repro should result in the server-side incrementing the user version number, and forcing all other clients to be uncollapsed. For the original repro, the reconnecting client’s change would only be tentative, so once it resyncs it would re-apply the original collapse state it had for the item (collapsed), which would make it consistent with the other clients.

[Shida]

I followed your steps and got a repro. Upon further investigation this is caused by a bug in the sync algorithm where anytime you upload changes, but there are remote changes to be downloaded, the server rejects the upload, but the collapse changes were discarded accidentally and not uploaded on retry.

A fix has been prepared and has been deployed to web.

[Jayden_Navarro]

@shida Thanks for fixing that. I still have some questions about the new “collapsed item with no children” behavior I’m seeing (repro steps here: Collapsing item on mobile not getting synced to web).

This new behavior manifests when you add the first child to an item with no children that was previously in a collapsed state before its last child was removed, using either of these two methods:

1. Zoom into the item and add the first child.
2. Add the first child via API (e.g. Quick Dynalist).

Previously an item with no children was always considered uncollapsed, so adding the first child would have it remain uncollapsed. With the new behavior the previously collapsed item becomes collapsed when the first child is added using these two methods, but is uncollapsed if added by hitting “Enter” and indenting.

Was this change intentional? It’s slightly confusing from a usability perspective that the collapse state is sticky, as there’s no way to tell the difference between childless items that are “collapsed” and ones that are “uncollapsed”.

Overall I’m fine with this new behavior as it fits in with how I use collapsed items + API, but I just wanted to make sure that this change was intentional.

Also, do you have an ETA for when the Android app will be updated? Since the Android app does not exhibit this behavior yet it’s now sometimes uncollapsed even when it’s collapsed on all other clients which is kind of annoying.

[Shida]

Yes it was intentional - previously the “uncollapsing when last child is removed” behavior is done in a deeper position that doesn’t allow the change to be tracked and synced, so we had to remove that behavior to allow proper sync of collapse states. Now it only does that when you indent items into a collapsed item, so the user experience remains relatively close (but there are edge cases as you mentioned).