Changes to Relations are discarded upon app restart

[edwards]

Describe the bug
Changes to stored global Relation properties (ones that persist and are “memorized” across multiple Objects), such as:

• “Restrict Object type” within the Object Relation
• Statuses stored within Status Relation
• Tags stored within Tag Relation
  - for example, there have been reports of changes to a Tag’s color is reverted upon restart Tags memorized within a relation seem inconsitent

… are discarded upon the app restarting. I believe this has been in the app since I first started using it - it’s been here for a long time.

The changes that causes this bug can be deletion, and modification. All the changes will be rolled back upon an app restart.

To Reproduce
Steps to reproduce the behavior:

1. Create a new Relation that supports global state, such as the ones I’ve listed above.
2. Add a new global state. Some examples are listed above (e.g, adding a new Tag, or adding a new Object type restriction)
3. Use the newly created Relations for a while, by adding them to a Type and creating various Sets and Objects from that type.
4. After sufficient usage of the Relation, try to modify the global stored state of it. Examples might be deleting a Tag, changing the color of a Status, or adding new Object restrictions.
5. Restart the app. The changes should be reverted.

Expected behavior
I expected changes I’ve made to a Relation’s global state to be accurately reflected across all Objects with that relation (which seems to be the cause of the issue), and for it to persist upon an app restart.

System Information:

• OS: MacOS 12.5
• Device Manufacturer/Model: MacBook Air M1
• Anytype Version: 0.27.0, although this has been in the app for about a year.

Additional context
There’s a few bug reports here that appear to show the same bug, but are only limited to Tags, and do not expand the scope to all Relations that contain stored global state.

Tags do not show up

I create a bookmark type/set with a tags-object. Often when i want to add tags that i now for sure that are already exsists the tags do now show. First i have to go to the home and than open the specfic bookmark-object again. If i than add a tag the tags do show. See screenshots below. Describe the bug When i want to add an existing tag the tags do now show To Reproduce Select a tag Expected behavior All tags showing System Information: MacOS 11 - Powerbook Pro 2016 - 2,7 GHz Quad-Co…

Tags memorized within a relation seem inconsitent

Describe the bug When I add tags to a relation they seem to disapear / sometimes not show when adding new tags, leading to make having to “create” the same tags over and over. (=Sometimes the tag is not in the proposed dropdown list and cannot be found by searching) It also seem like some tags cross over other relations. MULTIPLE TAGS ON AN OBJECT [image] THE TAGS DO NOT APPEAR IN THE DROPDOWN ON ANOTHER OBJECT [image] THE TAGS APPEARING SEEM INCONSITENT (=here “arythmies” should appear …

Status property gets lost all the time

Status property on type book. Can assign it perfeclty, but two minutes later it disappears on each device. Sync was successfully before cant clearly say why this is the case, after which step it happens This time, in set view it is visible, in page not … platform: linux manjaro, android

Additionally, here’s a video showcasing this issue. Note that in the video, one of the tags are revived even though the app was not restarted.

BTW, file uploads need to be fixed on the forums. A 18MB video file fails to upload with the error “Sorry, this file is too big.”

[sambouwer]

Just as a note on the uploads: I think this is mainly caused by the file format or video container used. I’ve uploaded (video) files larger than 1b without an issue, but also had trouble uploading a specific video file of just a couple megabytes. Not sure if video format compatibility is listed anywhere…

[kerbless]

+1, I think this is what happens to me as well, I described it as “Sometimes changes made to status relations get reverted.” (see A comprehensive anytype first impression).