Severe cache bug during submission on deposit

[atarix83]

Describe the bug
When a new submission that contains a relationship issue is created a severe cache bug occurs which doesn't allow to deposit the item.
Essentialy if all the changes in the submission have been saved, before to deposit the application try to retrieve the submission object again to check if the item can be deposited (it happens here). In the case the changes of the submission are not yet saved before to add a new relationship field they are saved when the relationship is added. This probably cause a cache problem and when the user try to deposit the item the application can't retrieve the updated submission object (it happens here) because it gets a remote data with status error stale and this leads to an endless loop of request to REST server.

To Reproduce
It can be reproduced in the sandbox environment also

1. as submitter try to create a new publication in the collection Publication 2 which have a relationship field
2. start to fill out the form following this order and without clicking on save:

• accept the license
• add the titlke and the date that are mandatory
• add an author
• upload a file

3. click on deposit
4. the submission is hanging forever and in the network endless requests are sent

Untitled_.Oct.26.2023.9_46.AM.mp4

Untitled_.Oct.26.2023.9_46.AM.webm

Expected behavior
The submission should be deposited

Related work
It's important to retrieve every time a fresh submission object because of the bug already resolved #1502

[artlowel]

@atarix83 The problem seems to be caused by the reRequestOnStale feature, if you set that to false, in the call you mentioned, the problem goes away.

Since the submission always manually re-retrieves the submission objects it shouldn't be necessary anyway so disabling it shouldn't affect the functionality.

However I do think there's still a bug in that reRequestOnStale feature, in a complicated case like this. If i log the number of calls to the findByID method for that same submission object, that are still subscribed when the bug occurs, I count 6. Some with reRequestOnStale true, others false. Then we also manually re-retrieve the object in the effect (by setting useCachedIfAvailable to false). I suspect this causes an edge case where the request that one of these subscriptions makes gets immediately set to stale by one of the others, causing the reRequestOnStale to trigger, which sets it to stale again, causing an infinite loop

So I'd try the workaround of disabling reRequestOnStale in the effect, see if it doesn't break anything, and if it doesn't merge that now. But leave the issue open to look into in more detail later

[atarix83]

thanks @artlowel for your analysis. i can confirm your solution works.
I've also find out that if i change the request by including the item and collection embeds it works as well even with reRequestOnStale as true.
I've tried it becuase i notice that there are two requests done endlessly. the first one with just the submission id and the other one with also item and collection embed

Maybe it can help to better understand the bug.

In the end i agree to temporary fix the issue in one of the two way and then to try to find out the problem in this edge case

[hutattedonmyarm]

I'm positive, that this is related to #1924. I observed the same pattern of endlessly re-requesting on stale