Changes in Channel details are not seen saved right away on click Save Changes but need page refresh to appear

[metodimilevqa]

Summary

Changes in Channel details are not seen saved right away on click the Save Changes button. If the user makes a change and clicks Save Changes and then gets back to the channel details page the changes are not seen but they appear on page refresh.

Category

BUG

Usage Details

Experienced at: https://hotfixes.studio.learningequality.org/

• Windows 10
• Browser: Chrome, Firefox, Edge (latest)
• Channel: Each channel

How to reproduce

Preconditions: Channels already created

1. Login to Studio
2. Click a Channel
3. Click the pencil icon to load the channel's details page
4. Make some amendments of the existing details
5. Click Save Changes button
6. Click again the pencil icon
7. See the changes made are not visible
8. Reload the page
9. See the changes made are now visible

Screenshots

[MisRob]

This seems to work well if you wait for /sync to finish when still on the channel details page.

However, there are two different issues that can cause this problem, depending on leaving/opening the edit channel details page and /sync call timing:

(1) Content defaults fields are displaying outdated values when I save changes and close the edit channel details page before /sync request, and then open the page again after /sync request

It could be quite common to run into this situation and I think that's most likely what @metodimilevqa experienced. It's caused by the content defaults component not receiving updates reactively from its mother component. A fix is here #3013.

(2) All fields are displaying outdated values when I save changes, close the edit channel details page, and open it again, all that before /sync gets called

This may not be as high priority as (1) because in this case, all steps need to be finished very fast. It's possible to run into it, however, and it reveals issues that might be eventually causing problems elsewhere.

I recommend testing it on a branch with the fix for (1) to avoid confusion. To reproduce, please go through all the following steps before sync\ gets called. Unless I missed something else happening in between the following steps, I think that I might know what's going on, and am adding some notes:

1. Assume that we have a channel with the description "Description 1".

2. I go to that channel's edit details page

3. Update the channel's description to "Description 2"

4. Click "SAVE CHANGES"

   UPDATE_CHANNEL mutation is properly committed with payload { description: "Description 2" }

5. I close the channel's edit details page

6. I am taken to the channel editor page

   • Where channel data is loaded
   • IndexedDB's channel table is updated with data fetched by fetchModel. Notice that fetched channel description is still "Description 1" because sync/ call with a new description hasn't finished yet.
   • Which causes Dexie's change event to be emitted with the following mods in its payload {description: "Description 1", __last_fetch: 1614932065020}. "Description 1" is in mods because before calling fetchModel, the new description "Description 2" had already been saved to the table.
   • Because UPDATE_CHANNEL mutation is registered as a callback for this change event, UPDATE_CHANNEL is called with payload { description: "Description 1" }. I checked the call stack to be sure that this mutation is not triggered from somewhere else in the code:
   

7. Because of that, when I open the channel's edit details page again, "Description 1" is displayed instead of the new "Description 2"

8. I need to reload the page or close it and open it again to see up-to-date "Description 2"

Note: I haven't discovered any issues with sync/ timing or conflicts in regards to saving data to backend. sync/ mechanism seems to be clever - even when we fetch the channel with its old data before it gets updated with new data, sync/ is called with a correct, new, payload { description: "Description 2" }

@bjester @micahscopes @rtibbles I am not sure about the next steps. Forcing sync on "SAVE CHANGES" button click could solve it but I'd prefer to avoid it and rather figured out a higher-level solution as I imagine that we might easily run into similar situations whenever we fetch data before syncing them, and debugging such issues can take a lot of time.

Would it make sense to ensure that we don't fetch data before sync finishes or have another mechanism in place to deal with such scenarios?

[MisRob]

Related #3018

[MisRob]

Reopening - even though #3013 resolved the issue under certain sync timing circumstances when steps to reproduce are followed fast enough, it's still broken - see (2) of #2888 (comment)