Enable Background Job Progress Report in bit Boilerplate based projects without SignalR (#11662)

[ysmoradi]

closes #11662

Summary by CodeRabbit

• Refactor
  • Reorganized background job progress notification messaging for improved routing efficiency.
  • Enhanced role management notification handling with conditional SignalR support.
  • Updated documentation for job progress notifications to reflect general long-running operation support.

[coderabbitai]

Walkthrough

Changes extend background job progress notification handling to support projects without SignalR by introducing a client-side message constant as an alternative channel, updating documentation for broader applicability, and conditionally including user session context in notifications based on SignalR configuration.

Changes

Cohort / File(s)	Summary
Background Job Progress Messaging src/Shared/Services/SharedAppMessages.cs, src/Client/Boilerplate.Client.Core/Services/ClientAppMessages.cs	Added BACKGROUND_JOB_PROGRESS constant to ClientAppMessages.cs to enable job progress notifications in non-SignalR environments. Updated XML documentation in SharedAppMessages.cs from Hangfire-specific language to generic job progress terminology.
Progress Subscription Update src/Client/Boilerplate.Client.Core/Components/Common/JobProgress.razor.cs	Changed PubSub subscription from SharedAppMessages.BACKGROUND_JOB_PROGRESS to ClientAppMessages.BACKGROUND_JOB_PROGRESS to use the new client-side message channel.
Notification Session Context src/Server/Boilerplate.Server.Api/Controllers/Identity/RoleManagementController.cs	Added conditional compilation directive around RequesterUserSessionId assignment in push notification call, only including session context when SignalR is enabled.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify both SharedAppMessages.BACKGROUND_JOB_PROGRESS and new ClientAppMessages.BACKGROUND_JOB_PROGRESS are properly used in their respective contexts
• Confirm conditional compilation logic correctly gates RequesterUserSessionId without affecting notification payload structure in either SignalR or non-SignalR paths
• Validate documentation changes accurately reflect the generalized use case

Poem

🐰 A progress bar hops without a link,
Now both paths shine, no missing sync!
With client and shared in harmony's dance,
JobProgress leaps—no SignalR need!
✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: enabling background job progress reporting in boilerplate projects without SignalR, matching the core objective of the PR.
Linked Issues check	✅ Passed	The PR implements the required fix by switching from SharedAppMessages to ClientAppMessages for background job progress, enabling the feature in non-SignalR environments as required by issue #11662.
Out of Scope Changes check	✅ Passed	All changes directly support the objective: switching message channels for non-SignalR compatibility, updating documentation, and conditionally including session IDs for SignalR scenarios.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Common/JobProgress.razor.cs (1)

27-29: Consider updating the comment for accuracy.

The comment on Line 28 states that the message is published from the server through SignalR. With this PR's changes, the message can also be published client-side when SignalR is disabled. Consider updating the comment to reflect both scenarios.

Apply this diff to clarify the comment:

                 var jobProgress = payload is JsonElement jsonDocument
-                    ? jsonDocument.Deserialize(JsonSerializerOptions.GetTypeInfo<BackgroundJobProgressDto>())! /* Message gets published from server through SignalR */
+                    ? jsonDocument.Deserialize(JsonSerializerOptions.GetTypeInfo<BackgroundJobProgressDto>())! /* When SignalR is enabled, message gets published from server */
                     : (BackgroundJobProgressDto)payload;

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between dabe941 and d7e4194.

📒 Files selected for processing (4)

• src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Common/JobProgress.razor.cs (1 hunks)
• src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientAppMessages.cs (2 hunks)
• src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/RoleManagementController.cs (1 hunks)
• src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/SharedAppMessages.cs (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build and test

🔇 Additional comments (4)

src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/SharedAppMessages.cs (1)

83-83: LGTM! Documentation updated appropriately.

The documentation change makes the description more general and applicable to various background job implementations, not just Hangfire-specific scenarios. This aligns well with the PR objective to support projects without SignalR.

src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Common/JobProgress.razor.cs (1)

23-23: LGTM! Key architectural improvement for SignalR-optional support.

The switch to ClientAppMessages.BACKGROUND_JOB_PROGRESS correctly enables the feature to work in both SignalR and non-SignalR scenarios. When SignalR is enabled, ClientAppMessages inherits from SharedAppMessages, so the constant remains the same. When SignalR is disabled, ClientAppMessages defines its own constant for client-side pub/sub.

src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientAppMessages.cs (1)

77-80: LGTM! Correctly placed constant for non-SignalR scenarios.

The BACKGROUND_JOB_PROGRESS constant is correctly placed inside the #if (signalR != true) block. This design ensures:

• When SignalR is enabled: ClientAppMessages inherits the constant from SharedAppMessages
• When SignalR is disabled: ClientAppMessages defines its own constant for client-side pub/sub

The documentation is consistent with the updated SharedAppMessages version, completing the architectural pattern for SignalR-optional support.

src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/RoleManagementController.cs (1)

239-241: Conditional compilation and null-safety are properly implemented.

The code correctly handles RequesterUserSessionId through multiple safety layers:

1. Field is nullable (Guid?) in the DTO, making it optional by design
2. Controller conditionally sets it only when SignalR is enabled (lines 239-241)
3. Job runner explicitly checks for null before accessing it: if (request.RequesterUserSessionId != null) (line 51 in PushNotificationJobRunner.cs)
4. Both the field and its usage are conditionally compiled, ensuring clean removal when SignalR is disabled

When SignalR is disabled, the field doesn't exist in the compiled code, and the job runner's session ID lookup block is also removed. No null reference exceptions will occur.