[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.25%. Comparing base (cf45fae) to head (4e91f81).
✅ 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.20%   81.25%   +0.05%     
==========================================
  Files         670      670              
  Lines       42920    42901      -19     
  Branches     7113     7112       -1     
==========================================
+ Hits        34853    34861       +8     
+ Misses       6917     6889      -28     
- Partials     1150     1151       +1     

☔ 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.