Setting a `belongsTo` relationship does not clear the previous triple/relationship

[elpoelma]

Describe the bug
When setting/overwriting a belongsTo relationship using the JSON:API, the previous triple/relationship doesn't always get cleared.

To Reproduce
Below are steps on how to reproduce this in GN, but it should also be easy to reproduce in any other app:

• Check-out https://github.com/lblod/app-gelinkt-notuleren/tree/v5.37.1
• Start the stack + ensure migrations have run
• Open the frontend on port 80
• Mock-login as any user
• Open/create a meeting.
• Add some agendapoints to that meeting
• In section 3 of the meeting reorder/remove some agenda items:
  
• The above action ensures that some belongsTo relationships are overwritten, as each agenda-item has a relationship with the previous agendapoint in the list (using the vorigeAgendapunt relationship). It is this relationship that does not get correctly overwritten
• Open the 'Sign and publish' screen and open the 'Planned agenda' section. Notice that a few agendapoints pop-up multiple times.

If I find the time, I'll create an easier reproduction of this issue.

Expected behavior
The vorigeAgendapunt relationship are correctly cleared when setting them.
In the 'Planned agenda' section, each agendapoint is only displayed once.

Notes
The regression/bug seems to have been introduced in 611482c

Versions/environments

• mu-cl-resources 1.25.0
• GN 5.37.1

[madnificent]

I went through the process and after reordering, it seems everything is rendering as expected.

Further trying and deleting two of the 5 agendapoints I indeed see a point which is duplicated. I don't know what I'm looking at exactly nor how the frontend code works. Assuming that list should effectively render agendapunt something is likely off in the frontend code itself. Blindly assuming the content should come from http://localhost/zittingen/6750886B68F25B60880C365E?include=aanwezigen-bij-start,agendapunten,secretaris,voorzitter (which may well be wrong), that payload contains three included resources. The Ember Inspector also doesn't show too many resources.

I do see a mix of cache and resource are used in the backend which could cause a cache not to be invalidated. Yet based on the information I have, I don't readily see how that would cause the behaviour I see here. Seeing the same item multiple times in the same list, I would first check if these have the same identifier. Limiting the relevant calls to the database would greatly help in figuring out if this is something in resource, something in Ember Data, or something in custom frontend code.

I don't think it's really feasible to debug this from a mu-cl-resources perspective. Best I could do is dig into the source code of gelinkt-notuleren under the assumption it didn't deviate from the suggested best practices and work my way from there.

[elpoelma]

Update:
A simple reproduction of this issue is included in https://github.com/elpoelma/frontend-mu-cl-resourceds-bug-repro and https://github.com/elpoelma/app-mu-cl-resources-bug-repro .