[RaymondLuong3]

The build history on the generation draft page can display incorrect information. The Project Notification Service listens for notifications and sends messages using signal R. This means that a project may be listening to the notification and that notification does not necessarily apply to the current project.

UPDATE:
This PR updates how consumers use the project notification service. Consumers now subscribe to observables that directly expose SignalR events. These subscriptions are automatically unsubscribed and the connection is closed when all subscriptions have been unsubscribed.

---

This change is 

[codecov]

Codecov Report

❌ Patch coverage is 75.80645% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.30%. Comparing base (67cffac) to head (81f2b2c).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...ate/draft-generation/draft-notification.service.ts	0.00%	4 Missing ⚠️
...lientApp/src/app/core/notification-service-base.ts	89.28%	3 Missing ⚠️
...ntApp/src/app/core/project-notification.service.ts	0.00%	3 Missing ⚠️
.../app/sync/sync-progress/sync-progress.component.ts	71.42%	2 Missing ⚠️
...aft-import-wizard/draft-import-wizard.component.ts	60.00%	2 Missing ⚠️
...late/editor/editor-draft/editor-draft.component.ts	85.71%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4191      +/-   ##
==========================================
+ Coverage   81.24%   81.30%   +0.05%     
==========================================
  Files         671      671              
  Lines       43040    43021      -19     
  Branches     7133     7138       +5     
==========================================
+ Hits        34967    34977      +10     
+ Misses       6906     6877      -29     
  Partials     1167     1167              

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

[Nateowami]

@Nateowami made 1 comment.
Reviewable status: 0 of 11 files reviewed, 1 unresolved discussion (waiting on RaymondLuong3).

---

src/SIL.XForge.Scripture/ClientApp/src/app/core/notification-service-base.ts line 61 at r1 (raw file):

   * @param owner The same object that was passed to start().
   */
  stop(owner: object): Promise<void> {

Thanks for tracking down the cause and fixing this. My first thought in reading this start/stop code with owner objects is that this feels exactly like an observable that needs to be unsubscribed when it's no longer needed, and that manually implementing start/stop which the consumer has to remember to call means there's more work in every class that uses it.

I asked Claude to look into implementing this with observables, and it appears while it's not trivial, the consumers get a better experience. I haven't reviewed it, but I pushed it to refactor/sf-3959-notification-observables. To me it looks like the consumers would be a lot simpler and less error-prone.

What do you think?

[RaymondLuong3]

@RaymondLuong3 made 1 comment.
Reviewable status: 0 of 19 files reviewed, 1 unresolved discussion (waiting on Nateowami).

---

src/SIL.XForge.Scripture/ClientApp/src/app/core/notification-service-base.ts line 61 at r1 (raw file):

Previously, Nateowami wrote…

Thanks for tracking down the cause and fixing this. My first thought in reading this start/stop code with owner objects is that this feels exactly like an observable that needs to be unsubscribed when it's no longer needed, and that manually implementing start/stop which the consumer has to remember to call means there's more work in every class that uses it.

I asked Claude to look into implementing this with observables, and it appears while it's not trivial, the consumers get a better experience. I haven't reviewed it, but I pushed it to refactor/sf-3959-notification-observables. To me it looks like the consumers would be a lot simpler and less error-prone.

What do you think?

Ok, I looked through the code and I can see the simplification for the consumer components. The project-notification service handles the closing of the connection when a component unsubscribes for the SignalR observable. I think this is an improvement on the current behaviour. I tested this for draft generation and draft applying and everything is behaving as I would expect.

[pmachapman]

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

---

src/SIL.XForge.Scripture/ClientApp/src/app/translate/draft-generation/draft-notification.service.ts line 34 at r2 (raw file):

/** Whether the state is the final notification sent after applying a draft, whether it succeeded or failed. */
export function isDraftApplyFinished(state: DraftApplyState): boolean {

This function does not need to be exported.

Code quote:

export function isDraftApplyFinished(state: DraftApplyState): boolean {

[pmachapman]

I think this is ready for testing. Just a minor non-blocking suggestion.

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

[pmachapman]

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