Description of the bug
When I make some changes to a cards body, which I discard by exiting edit mode using the cancel button, these changes are not applied to the card, as expected. However, when I re-enter edit mode, the changes are reapplied to the contents.
Yet another cancellation followed by entering edit mode a third time eventually discards those changes completely.
Hey, thanks for the report. It looks like this is an issue with the real-time syncing cache (which should be cleared when you cancel a card, but appears to not be in this case).
We will take a look and hopefully figure out what is going wrong.
Thanks for reporting back. At the moment we are erring on the side of safety, i.e. if something goes wrong we opt to leave the cached changes alone rather than delete them. Probably we don’t want to go the other way, so really we just need to figure out what is going wrong in these cases. It only seems to happen in a tiny, tiny fraction of cancellations though so we have struggled to replicate.
For me, markup text I remove remains removed after re-entering edit mode (for the first time after cancelation), while previously added text is not re-added, as it shouldn’t. This behavior is consistently reproducable (Android 3.1.3) with new cards as well with existing cards.
This behavior applies only when connected. In offline mode, everything works as intended.
This has been fixed as of Supernotes 3.1.4, however you may still encounter this occasionally.
We’re erring on the side of not deleting data if requests fail so it may appear that previously added text returns – however it should sort itself out now once the subsequent request successfully goes through.
Let us know how you get on, as always we’re here to help
Thanks for the heads up. This was a pre-existing issue with the real-time collaboration cache (as that is what was causing these issues in the first place). As part of the update we did not clear those, but we have cleared them for you now, so hopefully you should not be seeing this behavior any longer.
We’ve looked into this further recently, and found the cause in one of the libraries we use for collaboration merging / handling – so we’ve marked this as an upstream issue. We’re investigating workarounds for this currently.
Although the upstream limitations still exist, we attempted to ameliorate this as much as possible in Supernotes 3.1.6. I’m not entirely happy with the robustness of this solution, but after extensive testing it does seem to work consistently.
Please let us know if you are still seeing this issue.
