updated docs

docs/docs/config/cronJobs.md

@@ -111,7 +111,7 @@ where
 
 ## Re-dispatch Broadcast Push Notifications
 
-This cron job re-dispatches a broadcast push notifications when original request failed. It is part of [guaranteed broadcast push dispatch processing](../config/notification.md#guaranteed-broadcast-push-dispatch-processing)
+This cron job re-dispatches a broadcast push notifications when redis cluster fails. It is part of [guaranteed broadcast push dispatch processing](../config/notification.md#guaranteed-broadcast-push-dispatch-processing)
 
 The default config is defined by _cron.reDispatchBroadcastPushNotifications_ config object in file _/src/config.ts_
 

docs/docs/config/internalHttpHost.md

@@ -12,10 +12,10 @@ module.exports = {
 };
 ```
 
-then the HTTP request will be sent to the configured host. An internal request can be generated, for example, as a [sub-request of broadcast push notification](../config-notification/#broadcast-push-notification-task-concurrency). _internalHttpHost_ shouldn't be accessible from internet.
+then the HTTP request will be sent to the configured host. An internal request can be generated, for example, by [cron jobs](../config-cronJobs/). _internalHttpHost_ shouldn't be accessible from internet.
 
 All internal requests are supposed to be admin requests. The purpose of _internalHttpHost_ is to facilitate identifying the internal server ip as admin ip.
 
 ::: tip Kubernetes Use Case
-The Kubernetes deployment script sets <i>internalHttpHost</i> to _notify-bc-app_ service url in config map. The source ip in such case would be in a private Kubernetes ip range. You should add this private ip range to <a href="#admin-ip-list">admin ip list</a>. The private ip range varies from Kubernetes installation. In BCGov's OCP4 cluster, it starts with octet 10.
+The Kubernetes deployment script sets <i>internalHttpHost</i> to _notify-bc-app_ service url in config map. The source ip in such case would be in a private Kubernetes ip range. You should add this private ip range to <a href="../config-adminIpList/">admin ip list</a>. The private ip range varies from Kubernetes installation. In BCGov's OCP4 cluster, it starts with octet 10.
 :::

docs/docs/config/notification.md

@@ -59,7 +59,7 @@ The config items in the _value_ field are
 
 ## Broadcast Push Notification Task Concurrency
 
-To achieve horizontal scaling, when a broadcast push notification request is received, _NotifyBC_ divides subscribers into chunks and submits a BullMQ job for each chunk. The chunk size is defined by config _broadcastSubscriberChunkSize_. All subscribers in a sub-request chunk are processed concurrently when the sub-requests are submitted.
+To achieve horizontal scaling, when a broadcast push notification request is received, _NotifyBC_ divides subscribers into chunks and submits a BullMQ job for each chunk. The chunk size is defined by config _broadcastSubscriberChunkSize_. All subscribers in a chunk are processed concurrently.
 
 The default value for _broadcastSubscriberChunkSize_ is defined in _/src/config.ts_
 
@@ -73,6 +73,12 @@ module.exports = {
 
 To customize, create the config with updated value in file _/src/config.local.js_.
 
+::: tip When to adjust chunk size?
+
+Redis memory footprint is inversely proportional to chunk size. Increase chunk size if Redis memory usage is approaching physical limit.
+
+:::
+
 ## Broadcast Push Notification Custom Filter Functions
 
 ::: warning Advanced Topic
@@ -122,18 +128,19 @@ The recommended way to install additional Node.js modules is by running command
 
 As a major enhancement in v3, by default _NotifyBC_ guarantees all subscribers
 of a broadcast push notification will be processed in spite of
-_NotifyBC_ node failures during dispatching. Node failure is a concern because
+node failures during dispatching. Node failure is a concern because
 the time takes to dispatch broadcast push notification is proportional
 to number of subscribers, which is potentially large.
 
+_NotifyBC_ is not only resilient to failures of _NotifyBC_ application nodes, but also
+entire _Redis_ cluster.
+
 The guarantee is achieved by
 
 1. logging the dispatch result to database individually right after each dispatch
-2. when subscribers are divided into chunks and a chunk sub-request fails, the original request re-submits the sub-request
-3. the original request periodically updates the notification _updated_ timestamp field as heartbeat during dispatching
-4. if original request fails,
-   1. a cron job detects the failure from the stale timestamp, and re-submits the original request
-   2. all chunk sub-requests detects the the failure from the socket error, and stop processing
+2. when subscribers are divided into chunks and a chunk job fails, the job is re-processed by BullMQ
+3. a chunk job periodically updates the notification _updated_ timestamp field as heartbeat
+4. if redis cluster fails, a cron job detects the failure from the stale timestamp, and re-submits the notification request
 
 Guaranteed processing doesn't mean notification will be dispatched to every
 intended subscriber, however. Dispatch can still be rejected by smtp/sms

src/common/common.service.ts

@@ -275,7 +275,6 @@ export class CommonService {
     } catch (ex) {}
     let httpHost;
     try {
-      // todo: re-evaluate order of httpHost
       if (subscription?.httpHost) {
         httpHost = subscription.httpHost;
       }