How we can deal with Error Loading Exploration issue after discarding the changes.

[rahat2134]

It occur very rare. why this occur? @seanlip @Nik-09 @nikitaevg @DubeySandeep @Radesh-kumar @Anthony-Alridge PTAL

[seanlip]

@rahat2134 I'm not sure, you'll probably need to check the code that leads to this pop-up. The first step is probably to find a reliable way to reproduce it.

[rahat2134]

It is probably lost-changes-modal.component.html

<div class="modal-header">
  <h3>Error Loading Exploration</h3>
</div>

<div class="modal-body">
  <p>
    Sorry! The following changes will be lost. It appears that your
    draft was overwritten by changes on another machine.
  </p>

  <p *ngIf="hasLostChanges">
    The lost changes are displayed below. You may want to export or copy and
    paste these changes before discarding them.
  </p>

  <oppia-changes-in-human-readable-form [lostChanges]="lostChanges">
  </oppia-changes-in-human-readable-form>
</div>

<div class="modal-footer">
  <button class="btn btn-secondary" (click)="cancel()">Close</button>
  <button class="btn btn-primary" (click)="exportChangesAndClose()">Export Changes and Close</button>
</div>

[rahat2134]

-> It occurs when we discard changes, but it occur very rarely.
-> I wasn't able to reproduce it in local, But I was able to catch it using acceptance testing.
-> Screenshot:

[seanlip]

I think what's needed here is a reproducible use case. In trying to create that, you might also want to try digging into the acceptance test to see which line of code is causing the issue (you can do this by adding a long wait after the line of code you suspect, running it locally, and seeing if the error appears).

But in general this is going to need some trial-and-error investigation, or analysis of the code to see what triggers this modal and some thinking about why it might be being triggered in this circumstance.

[rahat2134]

The reason behind this error is (As per acceptance tests) ->
•After saving the changes we have a text Auto saving..., sometimes after updating the title it discard the changes before it gets saved. So, We need to wait until our changes has been saved.
In desktop we can apply to wait for the pop up to visible and hide.

But in mobile view port we don't have that pop up so we need to add external timeout after updating the input bar to save the changes.

However I am not able to reproduce it without acceptance test because-> I am not able to discard the changes as fast as Puppeteer did.

[seanlip]

I don't quite understand exactly what is happening here ... what sequence of actions is being performed exactly? Can you list the sequence of actions in order (using numbered steps) based on the test, and specify in exactly which instruction the pop-up appears?

In any case, if you need to introduce an "Autosaving..." text in mobile, that should be fine as well.

[rahat2134]

The thing is we can't see Autosaving... text in mobile, It is hidden. It was the main reason. why test was flaking sometimes.

[seanlip]

Yes, so fix the underlying code to make it not hidden.

Also please respond to my first point re the sequence of actions.

[rahat2134]

I attempted that, but I don't think it's feasible. The navbar converted into a hamburger menu in the mobile viewport. And, Autosaving ... is visible in navbar only.
You can also see in previous pictures.

[seanlip]

Yes, I get that. But maybe on mobile you could put a separate indicator just below the navbar?

[rahat2134]

Let me make it clear ->
Our CUJ is : To save the changes, publish the changes, and discard the changes.
Previously our title was - Old title
We update the title -

updateTitleTo('New Title');

After this update, we are discarding the modifications. At times, the puppeteer operates so swiftly that it discards the changes before they can be saved. (As there is no 'Autosaving text' on mobile) This can lead to the issue.

On desktop, the autosaving text is available, allowing us to wait for it to disappear and reappear. However, on mobile, we must utilize an external wait to ensure that the changes have been saved.

Kindly inform me if further clarification is required.

[seanlip]

Thanks for clarifying, this helps. (One note btw -- the "autosaving" text is not a pop-up, so I suggest not calling it that. A popup is a dialog window or modal, and we don't have that here.)

I think the right thing to do is to think about this from the user standpoint. Suppose for some reason an autosave is taking a long time and the user discards. What should happen? Probably the autosave should be discarded. So I would suggest that a bug be filed for this (and ideally fixed) -- i.e. discard should cancel any autosaves in progress and not show the "lost changes" popup when it fails. (And for manual reproduction just add a wait in the backend that artificially makes the "save draft" take a really long time.)

[rahat2134]

@seanlip I have an idea. We can disable the 'discard' button until Autosave is in progress. This approach will also address the mobile view port. Let me know if you agree, and I will raise the issue and submit a PR by EOD. PTAL.

DisableDiscardButton.webm

[seanlip]

@rahat2134 I don't understand. What dropdown are you referring to? The video just shows some form edits but I don't see anything being disabled.

Also since the issue is on mobile then maybe you'd want to show a video to illustrate your idea on mobile.

[seanlip]

Ahh, you mean the little triangle, I think. Yeah .. it is a bit implicit but unlikely to bother anyone in practice, so I'm OK with that. Just leave comments in the code to explain why you're doing it so future devs have context.

Thanks for the suggestion.

[seanlip]

@rahat2134 Could you please put this question in one of the Q&A categories and mark the relevant option as "answered" if you feel that this thread is resolved? Thanks.

(Please also put future Q&A in one of those categories, not "General".)