SF-3913 Pause sending of ops to ShareDB if offline

[pmachapman]

Problem

I isolated the root of this issue to client 1 thinking it was offline, and so triggering the logic in TextViewModel.fixSegment() to not create blanks (see SF-2272 and SF-2722), but the client was not completely offline - it was just a flaky connection. Because an op was sent to ShareDB that cleared a segment, but did not create a blank in its place, another listening client creates the blank, and sends it to ShareDB. When client 1 comes back online, it can under certain circumstances become confused, as it will attempt to create a blank. This will often resolve correctly, but if other edits took place, duplication of segments can occur sometimes (but not all the time). The duplication results from ShareDB's resolution of any incoming and outgoing ops on the segment, and its attempt to reconcile them.

Resolution

To resolve this issue, I pause any updates being sent to ShareDB for the text document if Scripture Forge believes itself to be offline. Ops are resumed when Scripture Forge next is online. This means that the omission of blank ops by TextViewModel.fixSegment() is not replicated to ShareDB (it is not supposed to be as this is offline-only functionality to ensure offline edits do not corrupt valid incoming edits from other users - see SF-2272)

Other Solutions

As the root of this issue is blank ops, and the view model's handling of them, the only other solution I could come to is the currently mothballed SF-3437 / #3339.

---

This change is 

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.25%. Comparing base (b906996) to head (97f88c6).
⚠️ Report is 8 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...src/xforge-common/sharedb-realtime-remote-store.ts	0.00%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4088   +/-   ##
=======================================
  Coverage   81.25%   81.25%           
=======================================
  Files         670      670           
  Lines       43467    43479   +12     
  Branches     7132     7134    +2     
=======================================
+ Hits        35321    35331   +10     
+ Misses       6976     6963   -13     
- Partials     1170     1185   +15     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[RaymondLuong3]

@RaymondLuong3 reviewed 5 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on pmachapman).

---

src/SIL.XForge.Scripture/ClientApp/src/app/shared/text/text.component.ts line 1232 at r1 (raw file):

    if (!this.onlineStatusService.isOnline) {
      textDoc.adapter.pause();
    }

Do you think these lines are necessary? There may be a small window when the component initializes and the app is offline but onlineStatus$ has not emitted yet, but that window is so small. Is that what these lines are for?

Code quote:

    if (!this.onlineStatusService.isOnline) {
      textDoc.adapter.pause();
    }

[pmachapman]

@pmachapman made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on RaymondLuong3).

---

src/SIL.XForge.Scripture/ClientApp/src/app/shared/text/text.component.ts line 1232 at r1 (raw file):

Previously, RaymondLuong3 (Raymond Luong) wrote…

Do you think these lines are necessary? There may be a small window when the component initializes and the app is offline but onlineStatus$ has not emitted yet, but that window is so small. Is that what these lines are for?

Yes - I found it was necessary to do this in my testing.

[RaymondLuong3]

@RaymondLuong3 resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on pmachapman).