Even more reverts. :(
After additional testing (based on user reports) it seems like this may
still be causing issues. I find it weird and don't understand why, but
I'm reverting this as a precaution so people aren't affected.
Related to #97
This reverts commit da3ac48bbf.
This is not needed for proper deployments where the server properly locks
the database tables. But in some older etesync server versions and possibly
bad databases, this is not the case.
OpenTasks causes EteSync to concurrently try to sync, so this at least makes
sure this race condition doesn't happen for these rare cases.
A lot of reverts. :)
According to more information and testing in #97, this was indeed
unrelated and 1.9.3 was enough to fix it.
This reverts commit 73179318f3.
It seems like this is the cause of #97 as 19b4e2a796
hasn't fixed the issue. Still not sure why it's happening, but reverting
it so no more users suffer from this issue.
This reverts commit 26ea8900a2.
I'm pretty sure this was causing the recent issues with tasks and events
disappearing as described in #97.
Regardless of this, it's not actually needed as SQLite on Android is
already thread-safe. The SQLite locks some users were experiencing were
probably fixed in 26ea8900a2
This reverts commit 9ed172e23c.
Before this change we were fetching the journals 3 times each time (once
for each journal type).
This was wasteful both for the server and battery life. Now we just cache the
requests for a few seconds with the assumption that a burst most mean it's
the same sync operation.
This change was mostly flagging non-real issues, like connection reset
by peer. Revert for now and come up with an alternative solution.
This reverts commit d3ad17e0bb.
They inherit from IO exceptions so were temporarily ignored, but they could
indicate a real issue with the ability of this user to connect to the
server.
This change makes it easier to detect if a debug report was actually due to a
real issue, or is just a user sending the debug activity without any real
issue behind it.
This is to battle the surprising amount of debug info spam we've had to battle
with. Essentially users sending debug info without actually experiencing any
issues and never replying to questions. This is made worse because many of
those emails also have weird addresses in CC which make it look even more
like some weird sort of spam.
