May I ask, how long did you keep the app open after performing the share operation?
Weâve gotten multiple reports over the last few months but somehow I am still unable to reproduce this exact problem on our iOS device. If you have a way to reproduce the issue consistently, it would be really helpful if you can record a video of the exact steps so we can try to follow w.r.t. timing, etc.
Its possible those edits get synced to the server as later than the added links, and thus overwrites them. To avoid this it is absolutely necessary to be sure your edits are in a distinct part of your outline from where the links are sent. OR, be diligent about syncing.
The share extension now launches the app when creating the links. I usually switch back to whatever Iâm doing. But Iâve opened and worked on other documents in Dynalist for hours afterwords. It seems strange that the inbox wouldnât sync while Iâm doing that.
Iâm curious why the extension works this way. When I use the API via Drafts or the Dynalist Bookmarker Chrome extension I donât seem to have these problems. Moreover, I donât even have to launch Dynalist. (And as an added bonus I can even save things to other documents besides the inbox.) Why are these 3rd party solutions so much more robust than the Dyanlist share extension?
The Share extension is native iOS code that pushes the text to the (cordova) app, which inserts it as if youâre editing it using the app. I still havenât been able to find out why items inserted using this method doesnât sync whereas items inserted traditionally by typing syncs.
3rd party methods rely on the API which pushes the text directly to the server, then the apps would pull that change from remote.
This extension aside, Sync doesnât happen on an iPhone when DynaList isnât loaded and active. In particular, if Iâm working disconnected, then leaving the app then later connecting; such is not a valid multi-device process with DynaList. You can do the above, but you must go back into the app to give it time to sync. (Also, sync doesnât happen every millisecond; thereâs always a notable delay.)
My guess is this extension doesnât keep dynalist open for long enough to allow the sync process to complete.
This doesnât explain it, because the app is open otherwise and should have time to sync later on.
Oh, you are actively working in DynaList? Okay then.
I got bitten by this bug today as well. I shared a link from Overcast to Dynalist, I could see it in Inbox on the iPhone, but on the web it never appeared.
I added then some other text in the Inbox on the iPhone which, after a while, appeared in the web. But the link I originally shared from Overcast never appeared.
This is a deal breaker for me. Things like this make me not trust Dynalist at all, as I am now wondering what other things are just on the iPhone/iPad and not on the web.
Is this something the devs are looking into?
It is something weâre aware, but so far we havenât been able to find out the root cause yet. Weâre still looking for more reports of how it can happen, any data point helps!
If you notice any specific behavior that gets the bug to reproduce reliably please share it with us.
Of course, now when I tried to reproduce it, it worked 
Haha, yeah, weâre pretty frustrated about this issue too. As far as all the support channels weâre listening on, this seems to be the only remaining synchronization bug we have, so Iâd love to have it fixed. Thanks in advance!
All I can say is that, because of these concerns, I donât use the sharing extensions on iOS or Android but, instead, the specialized app Dynawrite on both platforms. No lost data when submitting Inbox items that way, as far as Iâm aware. (I think they get submitted to the server directly from Dynawrite.)
I realize itâs a workaround and doesnât help fixing the current issue with extensions. But itâs something Iâve got used to over time, and I have Dynawrite always within easy reach (for example, on my Android lock screen).
You have never yet addressed the problem of offline work. I canât safely work on a document offline because when it comes online thereâs a chance that unknown to me a node was erased on another machine and when I go online the sync erases all my work. You might say âExpected behaviorâ but thatâs not close to good enough.
I donât know, but itâs possible the sharing mechanism interacted with this misfeature of the sync mechanism and caused the lost data the OP writes about here.
I believe thatâs correct, they use the API to send directly to the server.
Thatâs generally dependent on how you work - If your work isnât shared with other users thereâs less chance of this happening. I think this is more of an edge case that most people can keep track to avoid. A more extreme example could be if you delete a document from another machine, but still expecting offline changes to sync to the deleted document. While I think itâs still reasonable, most people would consider that a pretty rare edge-case.
Itâs true that I am not sharing my work, but I still feel unsafe working offline. I have been bitten multiple times by this in the past, and so I simply resolve to always make sure I sync before leaving a device and sync before starting work on a different device. Itâs the only way to be safe, and that means never going a place where thereâs no wifi to work.
Just to update all of you on this issue: I have reproduced the problem, nailed down the exact cause of the issue, came up with a patch which fixes the issue and verified the fix to be working.
We will be pushing an update out soon!
For anyone interested in a technical overview of the bug:
Internally, dynalist uses a âdiffâ system to sync changes to the server. We store a local copy of your current Dynalist file, and a local copy of the âlast syncedâ Dynalist file. When itâs time to send changes to the server, a âdiffâ is created by comparing these files and summarizing the difference.
When we compute the diff, an additional step of optimization is done to avoid scanning the whole file: we mark each item with a version number, and when theyâre edited locally, the version number is bumped to indicate that itâs been changed. When computing a diff, any item with version numbers below the last synced number is ignored.
When you capture an item right after starting the app (i.e. when you share from another app), thereâs a chance you click the button before the destination inbox document is loaded. We wait until itâs loaded before sending the item and showing a confirmation dialog.
The issue is caused by the fact that
To fix the issue, Iâve made 2 changes. Either one of them should fix the issue, but I want to make things right:
The reason why itâs difficult to reproduce this issue is that most of the time, the document is already loaded. Or if your phone is fast enough, it might be loaded before you click on the capture button.
Wow. Great news on figuring this out! (Also thanks for the clear explanation which makes total sense to me even though I am not myself a software developer.)
Hmm. Donât know if this should be a new thread or not, but I found that items can be slow to show up (although they do eventually), if I move them after adding to inbox.
The changes to document X are not synced. I then open that target document on iOS and force refresh. It syncs, but at first the newly added item doesnât appear. Later, however, it finally shows up.
Not exactly sure what is going on here, but sync is far from as smooth or responsive as it should be so I thought Iâd mention it just in case anyone else here sees something similar happening.
I believe this fix has been released in our last mobile deployment already. Will be deploying new one today anyway so Iâll mark it as fixed.