Silent sync failure behind corporate proxy, data loss scenario

Bug report

Observed this in the following conditions:

  • launch inkdrop without any proxy configuration in place (e.g, do not configure .cson file).
  • connect to a network that uses a corporate proxy for web access.
  • create a new note and edit it, then save.
  • sync indicator at bottom left indicates a recent sync, however note does not show up on other clients.
  • Requesting a manual sync completes OK without error, but not does not turn up on other clients.

I have not seen any issues reported under the developer tools. Would it be expected to create a synchronisation error in this case?

Switching from the corporate network to an open network then allows the sync to complete OK.

I have noticed that this situation can be used to create data loss though, e.g., by doing the following:

Using two clients, for example, “Client A” on normal internet, and “Client B” switching between a corporate proxy and open internet:

  • Edit note on “Client A” and save changes.
  • Note synchronises to “Client B”.
  • Switch “Client B” to a proxy connection (without configuring proxy information in .cson).
  • Update note on “Client A” and then “Client B”
  • Switch “Client B” from proxy to open connection.
  • When “Client B” syncs, it destroys the changes on “Client A” instead of creating a conflicted note.

Info

  • Platform: Windows 10 Enterprise
  • Platform version: 1909
  • App Version: 5.1.2

Reproduce

As above, for the silent sync failure:

  • create content while behind a corporate proxy or restricted internet connection, sync does not indicate any failure, but content is not synced.

For data loss scenario:

  • Update the same note across two different clients while one has restricted internet with a silent sync failure. When a normal connection is restored, data is lost from one update.

Hi Zed,

The app can’t sync if you are behind a corporate proxy.
You have to configure it:

Yes definitely! But I was confused about the false-positive around the sync completing, is that expected? I thought it might be better if it indicated that it couldn’t sync when it was blocked by a proxy.

Yeah, that makes sense.
For not only web proxy, but network errors also happen for various reasons, like disconnected environment, unstable network, Kerberos authentication, etc.
It is annoying to get noticed that it couldn’t sync due to those reasons if you are aware of them.
Besides, it is hard to distinguish if it is blocked by a web proxy because the error code/message is not always the same.

Yeah, is it appropriate or useful to do something similar to apple where they try and get a simple remote file (like inkdrop.app/test.txt) as a confirmation of external access? When it fails it gives you a general “bad network state” under a range of different disruptions.

I was curious though, how come the sync process still thinks it is OK when it cannot contact the users remote DB endpoint? Like in this case “https://store.inkdrop.app/user-xxxxxx” is likely to be getting a 403 auth error when it tries to sync?

Apologies, I meant to say: not a totally serious issue on my end, inkdrop is a very incredible experience for making notes and documentation, thank you! =) just got caught-out by the silent sync failure here.

You can know if there is a bad network state but I’m saying that it’s hard to distinguish if it’s by a web proxy or not.
PouchDB does not report errors for live sync but it just pauses syncing and retries automatically:
https://pouchdb.com/guides/replication.html#live–replication

Inkdrop checks the account state via the account API, not via the sync API. The auth session will be expired if it keeps failing.

Thanks for letting me your thoughts!

No, thank you for entertaining them. I feel like I’m taking up your time for little reason!

That makes sense with PouchDB, so by design of it’s resiliency it accepts intermittent network failures with the assumption that it will sync at a later point when the network resumes, so this kind of scenario does not look that unusual to it.

Is there any way to avoid the note conflict that can occur in that circumstance as per the second point in the original report?

1 Like

Inkdrop does not support auto-merging, so it is not possible at the moment.
But you can restore the old revisions:

1 Like

Great, thank you for your patience!

1 Like