Re-render GFM in deprecated notes when an update is received

Asherah Connorrequested to merge
push-psqunmurvlpo into master

What does this MR do and why?

No related issue, I just discovered this and decided to fix it in one go.

While looking into related bugfixes (#386219 (closed), #593663 (closed), !228395 (merged)), Duo happened to catch that the frontend will not correctly call renderGFM in the case where you're currently editing a note, that note is modified by someone else in the meantime, and then you cancel that edit.

Since the note is replaced, but renderGFM isn't called, any Mermaid diagrams in the edited note won't be rendered.

Screenshots or screen recordings

I've demonstrated this using two windows editing the same note. (I've cut the left-hand clip to remove a total of about a minute of waiting for ActionCable; when doing the right-hand one my GDK was being nicer.)

Note that in these videos I first edit the comment from one tab to make sure it propagates correctly to the other one. This isn't required to manifest the bug; I'm just ensuring they're both connected to ActionCable before repro'ing.

Before After

How to set up and validate locally

  1. Create a snippet comment with an embedded Mermaid graph, like this one: 
    ```mermaid
graph LR; A-->B
```
  2. Open the snippet in two different window.
  3. Start editing the comment in one window, but don't make changes; just leave the edit interface open.
  4. Edit the comment in the other window and save your change.
  5. Wait for the comment update to propagate to the first window: you'll see the comment source change in the edit textbox.
  6. Click cancel. You should see the edited comment with the Mermaid graph rendered.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports