Relations object of entry is not always properly updated
Description
Up to version 5.6 we had a bug that prevented the relations object from being used (see changes to getRelations() in this commit: )
This change appears to highlight another - until now undiscovered - issue that prevents the relations object from being updated properly.
This was discovered when testing Entryscape with the following scenario: User U is added to Group G. The request returns successfully, but Group G does not show up in the relations graph of User U. Reloading Entrystore solves this issue, the relations graph is properly until the user is added to another group. This indicates a concurrency issue, it seems as if the relations graph is loaded (and cached) before the group changes have been registered in the user’s relations graph.
Solution proposal:
Implement a test to reliably reproduce the problem (i.e., the test should fail).
Implement a solution to make the test go through.
Environment
None
Activity
Show:
Hannes Ebner March 24, 2025 at 3:59 PM
I was able to achieve synchronization of the relations cache with repo, but the solution required a lot of code and felt brittle towards future changes. Since we don’t cache any other graph objects such as metadata graphs I opted to remove the relations object from EntryImpl alltogether. As a side effect of this issue I refactored the code to only use Model instead of List for the relations graph.
Up to version 5.6 we had a bug that prevented the relations object from being used (see changes to getRelations() in this commit: )
This change appears to highlight another - until now undiscovered - issue that prevents the relations object from being updated properly.
This was discovered when testing Entryscape with the following scenario: User U is added to Group G. The request returns successfully, but Group G does not show up in the relations graph of User U. Reloading Entrystore solves this issue, the relations graph is properly until the user is added to another group. This indicates a concurrency issue, it seems as if the relations graph is loaded (and cached) before the group changes have been registered in the user’s relations graph.
Solution proposal:
Implement a test to reliably reproduce the problem (i.e., the test should fail).
Implement a solution to make the test go through.