@oneuptime/common 12.0.13 → 12.0.14

package/Server/Services/UserNotificationRuleService.ts

@@ -644,6 +644,14 @@ export class Service extends DatabaseService<Model> {
           deviceType: true,
           isVerified: true,
           userId: true,
+          /*
+           * Whether this handset asked to be rung through silent mode. Unselected
+           * it reads as undefined, which Boolean()s to false further down - the
+           * page still goes out, just quietly, which is the wrong outcome for the
+           * one channel a sleeping responder relies on. It is selected here so
+           * that cannot happen.
+           */
+          isCriticalAlertEnabled: true,
         },
       },
       props: {
@@ -2419,6 +2427,16 @@ export class Service extends DatabaseService<Model> {
       notificationRuleItem.userPush?.deviceToken &&
       notificationRuleItem.userPush?.isVerified
     ) {
+      /*
+       * This is the on-call paging path - the notification that exists to wake
+       * somebody at 3am - so it is the only push in the product allowed to
+       * override the ringer switch, and then only for a device whose owner
+       * turned the option on. Owner subscriptions and note-posted notifications
+       * go out through UserNotificationSettingService and never set this.
+       */
+      const isCriticalAlert: boolean = Boolean(
+        notificationRuleItem.userPush.isCriticalAlertEnabled,
+      );
       // send push notification for alert
       if (
         options.userNotificationEventType ===
@@ -2459,6 +2477,8 @@ export class Service extends DatabaseService<Model> {
             projectId: alert.projectId!.toString(),
           });
 
+        pushMessage.isCriticalAlert = isCriticalAlert;
+
         // send push notification.
         PushNotificationService.sendPushNotification(
           {
@@ -2540,6 +2560,8 @@ export class Service extends DatabaseService<Model> {
             projectId: incident.projectId!.toString(),
           });
 
+        pushMessage.isCriticalAlert = isCriticalAlert;
+
         // send push notification.
         PushNotificationService.sendPushNotification(
           {
@@ -2620,6 +2642,8 @@ export class Service extends DatabaseService<Model> {
             projectId: alertEpisode.projectId!.toString(),
           });
 
+        pushMessage.isCriticalAlert = isCriticalAlert;
+
         PushNotificationService.sendPushNotification(
           {
             devices: [
@@ -2699,6 +2723,8 @@ export class Service extends DatabaseService<Model> {
             projectId: incidentEpisode.projectId!.toString(),
           });
 
+        pushMessage.isCriticalAlert = isCriticalAlert;
+
         PushNotificationService.sendPushNotification(
           {
             devices: [

package/Server/Services/UserPushService.ts

@@ -12,6 +12,7 @@ import PositiveNumber from "../../Types/PositiveNumber";
 import PushDeviceType from "../../Types/PushNotification/PushDeviceType";
 import UserPush from "../../Models/DatabaseModels/UserPush";
 import CaptureSpan from "../Utils/Telemetry/CaptureSpan";
+import { LIMIT_PER_PROJECT } from "../../Types/Database/LimitMax";
 
 export class Service extends DatabaseService<UserPush> {
   public constructor() {
@@ -120,6 +121,94 @@ export class Service extends DatabaseService<UserPush> {
       },
     });
   }
+
+  /**
+   * Turn on-call critical alerts on or off for a handset.
+   *
+   * Keyed on the device TOKEN rather than a row id, because one phone owns one
+   * row per project it is registered against, and "ring me through silent
+   * mode" is a property of the phone. Toggling it per row would leave a
+   * responder loud for one project and silent for the next - a distinction
+   * nothing in the app offers to make and nobody would think to check.
+   * Deletion already works this way for the same reason (see the unregister
+   * route).
+   *
+   * Scoped to `userId` so a token cannot be used to reconfigure somebody
+   * else's device, and to the two mobile platforms because no browser can
+   * override a device's ringer: storing the preference on a web row would
+   * read back as though it did something.
+   *
+   * Returns how many rows were updated, so the caller can tell a real toggle
+   * apart from one that matched no device at all.
+   */
+  @CaptureSpan()
+  public async setCriticalAlertEnabledForDeviceToken(data: {
+    userId: ObjectID;
+    deviceToken: string;
+    isEnabled: boolean;
+  }): Promise<number> {
+    const devices: Array<UserPush> = await this.findBy({
+      query: {
+        userId: data.userId,
+        deviceToken: data.deviceToken,
+      },
+      select: {
+        _id: true,
+        deviceType: true,
+      },
+      limit: LIMIT_PER_PROJECT,
+      skip: 0,
+      props: {
+        isRoot: true,
+      },
+    });
+
+    if (devices.length === 0) {
+      throw new BadDataException(
+        "No registered device was found for this device token.",
+      );
+    }
+
+    const mobileDeviceIds: Array<string> = devices
+      .filter((device: UserPush) => {
+        return (
+          device.deviceType === PushDeviceType.iOS ||
+          device.deviceType === PushDeviceType.Android
+        );
+      })
+      .map((device: UserPush) => {
+        return device._id!.toString();
+      });
+
+    if (mobileDeviceIds.length === 0) {
+      throw new BadDataException(
+        "Critical alerts are only available on iOS and Android devices.",
+      );
+    }
+
+    let updatedCount: number = 0;
+
+    /*
+     * One update per row rather than an `_id: In([...])` query: the query
+     * builder used here takes a single value per column, and the count of
+     * projects a responder belongs to is small.
+     */
+    for (const deviceId of mobileDeviceIds) {
+      updatedCount += await this.updateOneBy({
+        query: {
+          _id: deviceId,
+        },
+        data: {
+          isCriticalAlertEnabled: data.isEnabled,
+        },
+        props: {
+          isRoot: true,
+        },
+      });
+    }
+
+    return updatedCount;
+  }
 }
 
 export default new Service();

package/Server/Services/UserSmsService.ts

@@ -15,7 +15,8 @@ import LIMIT_MAX from "../../Types/Database/LimitMax";
 import TwilioConfig from "../../Types/CallAndSMS/TwilioConfig";
 import BadDataException from "../../Types/Exception/BadDataException";
 import ObjectID from "../../Types/ObjectID";
-import Text from "../../Types/Text";
+import TooManyRequestsException from "../../Types/Exception/TooManyRequestsException";
+import ChannelVerification from "../Utils/ChannelVerification";
 import Project from "../../Models/DatabaseModels/Project";
 import Model from "../../Models/DatabaseModels/UserSMS";
 import CaptureSpan from "../Utils/Telemetry/CaptureSpan";
@@ -143,7 +144,8 @@ export class Service extends DatabaseService<Model> {
     createdItem: Model,
   ): Promise<Model> {
     if (!createdItem.isVerified) {
-      this.sendVerificationCode(createdItem);
+      // issue and send the first verification code
+      await this.issueAndSendVerificationCode(createdItem);
     }
 
     return createdItem;
@@ -158,9 +160,10 @@ export class Service extends DatabaseService<Model> {
       },
       select: {
         phone: true,
-        verificationCode: true,
         isVerified: true,
         projectId: true,
+        userId: true,
+        verificationCodeSentAt: true,
       },
     });
 
@@ -215,23 +218,54 @@ export class Service extends DatabaseService<Model> {
       );
     }
 
-    // generate new verification code
-    item.verificationCode = Text.generateRandomNumber(6);
+    /*
+     * Resend cooldown.
+     *
+     * Without it, spending the attempt budget on a code and asking for
+     * another one is free, which turns the attempt limit into a speed bump
+     * rather than a wall — and the resend control doubles as a way to send
+     * somebody unsolicited messages as fast as the network allows, at the
+     * project's expense.
+     */
+    const retryAfterSeconds: number =
+      ChannelVerification.getResendRetryAfterSeconds({
+        lastSentAt: item.verificationCodeSentAt,
+      });
 
-    await this.updateOneById({
-      id: item.id!,
-      props: {
-        isRoot: true,
-      },
-      data: {
-        verificationCode: item.verificationCode,
-      },
+    if (retryAfterSeconds > 0) {
+      throw new TooManyRequestsException(
+        `Please wait ${retryAfterSeconds} seconds before requesting another verification code.`,
+      );
+    }
+
+    await this.issueAndSendVerificationCode(item);
+  }
+
+  /*
+   * Mint a fresh code for this row, store only its digest, and send the
+   * plaintext to the channel.
+   *
+   * The plaintext exists in memory for exactly as long as it takes to hand it
+   * to the notification service and is never written anywhere. Everything
+   * about why — expiry, the attempt counter, rotation, the resend cooldown —
+   * is in Common/Server/Utils/ChannelVerification.ts.
+   *
+   * This does NOT check whether a send is allowed. Callers decide that:
+   * onCreateSuccess because a brand new row has never been sent to, and
+   * resendVerificationCode after the cooldown and the channel's own
+   * preconditions have passed.
+   */
+  @CaptureSpan()
+  public async issueAndSendVerificationCode(item: Model): Promise<void> {
+    const plainCode: string = await ChannelVerification.issueCodeOnItem({
+      service: this,
+      itemId: item.id!,
     });
 
-    this.sendVerificationCode(item);
+    this.sendVerificationCode(item, plainCode);
   }
 
-  public sendVerificationCode(item: Model): void {
+  public sendVerificationCode(item: Model, code: string): void {
     (async () => {
       const projectTwilioConfig: TwilioConfig | undefined =
         await ProjectCallSMSConfigService.getProjectDefaultTwilioConfig(
@@ -242,8 +276,7 @@ export class Service extends DatabaseService<Model> {
         {
           to: item.phone!,
           message:
-            "This message is from OneUptime. Your verification code is " +
-            item.verificationCode,
+            "This message is from OneUptime. Your verification code is " + code,
         },
         {
           projectId: item.projectId,

package/Server/Services/UserWhatsAppService.ts

@@ -13,7 +13,8 @@ import WhatsAppService from "./WhatsAppService";
 import LIMIT_MAX from "../../Types/Database/LimitMax";
 import BadDataException from "../../Types/Exception/BadDataException";
 import ObjectID from "../../Types/ObjectID";
-import Text from "../../Types/Text";
+import TooManyRequestsException from "../../Types/Exception/TooManyRequestsException";
+import ChannelVerification from "../Utils/ChannelVerification";
 import Project from "../../Models/DatabaseModels/Project";
 import Model from "../../Models/DatabaseModels/UserWhatsApp";
 import CaptureSpan from "../Utils/Telemetry/CaptureSpan";
@@ -139,7 +140,7 @@ export class Service extends DatabaseService<Model> {
     createdItem: Model,
   ): Promise<Model> {
     if (!createdItem.isVerified) {
-      this.sendVerificationCode(createdItem).catch((error: Error) => {
+      this.issueAndSendVerificationCode(createdItem).catch((error: Error) => {
         logger.error(error, {
           projectId: createdItem.projectId?.toString(),
           userId: createdItem.userId?.toString(),
@@ -159,10 +160,10 @@ export class Service extends DatabaseService<Model> {
       },
       select: {
         phone: true,
-        verificationCode: true,
         isVerified: true,
         projectId: true,
         userId: true,
+        verificationCodeSentAt: true,
       },
     });
 
@@ -176,22 +177,54 @@ export class Service extends DatabaseService<Model> {
       throw new BadDataException("WhatsApp number already verified");
     }
 
-    item.verificationCode = Text.generateRandomNumber(6);
+    /*
+     * Resend cooldown.
+     *
+     * Without it, spending the attempt budget on a code and asking for
+     * another one is free, which turns the attempt limit into a speed bump
+     * rather than a wall — and the resend control doubles as a way to send
+     * somebody unsolicited messages as fast as the network allows, at the
+     * project's expense.
+     */
+    const retryAfterSeconds: number =
+      ChannelVerification.getResendRetryAfterSeconds({
+        lastSentAt: item.verificationCodeSentAt,
+      });
 
-    await this.updateOneById({
-      id: item.id!,
-      props: {
-        isRoot: true,
-      },
-      data: {
-        verificationCode: item.verificationCode,
-      },
+    if (retryAfterSeconds > 0) {
+      throw new TooManyRequestsException(
+        `Please wait ${retryAfterSeconds} seconds before requesting another verification code.`,
+      );
+    }
+
+    await this.issueAndSendVerificationCode(item);
+  }
+
+  /*
+   * Mint a fresh code for this row, store only its digest, and send the
+   * plaintext to the channel.
+   *
+   * The plaintext exists in memory for exactly as long as it takes to hand it
+   * to the notification service and is never written anywhere. Everything
+   * about why — expiry, the attempt counter, rotation, the resend cooldown —
+   * is in Common/Server/Utils/ChannelVerification.ts.
+   *
+   * This does NOT check whether a send is allowed. Callers decide that:
+   * onCreateSuccess because a brand new row has never been sent to, and
+   * resendVerificationCode after the cooldown and the channel's own
+   * preconditions have passed.
+   */
+  @CaptureSpan()
+  public async issueAndSendVerificationCode(item: Model): Promise<void> {
+    const plainCode: string = await ChannelVerification.issueCodeOnItem({
+      service: this,
+      itemId: item.id!,
     });
 
-    await this.sendVerificationCode(item);
+    await this.sendVerificationCode(item, plainCode);
   }
 
-  public async sendVerificationCode(item: Model): Promise<void> {
+  public async sendVerificationCode(item: Model, code: string): Promise<void> {
     if (!item.projectId || !item.userId || !item.phone) {
       logger.warn("Cannot send WhatsApp verification code. Missing data.", {
         projectId: item.projectId?.toString(),
@@ -205,7 +238,7 @@ export class Service extends DatabaseService<Model> {
     const templateKey: WhatsAppTemplateId =
       WhatsAppTemplateIds.VerificationCode;
     const templateVariables: Record<string, string> = {
-      "1": item.verificationCode || "",
+      "1": code,
     };
 
     const whatsAppMessage: WhatsAppMessage = {

package/Server/Types/Database/QueryHelper.ts

@@ -51,6 +51,36 @@ export default class QueryHelper {
     );
   }
 
+  /*
+   * Case-insensitive `IN (...)` — the multi-value twin of
+   * findWithSameText. Used where a user-typed identifier has to match an
+   * ingest-stamped name that may differ only by case (monitor step
+   * configs vs. the resource rows discovered from telemetry), and where
+   * issuing one findOneBy per identifier would cost a round-trip each.
+   *
+   * An empty list would compile to `IN ()`, which is a syntax error, so
+   * callers must not pass one; they have nothing to look up anyway.
+   */
+  @CaptureSpan()
+  public static findWithSameTextAnyOf(
+    texts: Array<string>,
+  ): FindWhereProperty<any> {
+    const rid: string = Text.generateRandomText(10);
+
+    const normalizedTexts: Array<string> = texts.map((text: string): string => {
+      return text.toLowerCase().trim();
+    });
+
+    return Raw(
+      (alias: string) => {
+        return `(LOWER(${alias}) IN (:...${rid}))`;
+      },
+      {
+        [rid]: normalizedTexts,
+      },
+    );
+  }
+
   @CaptureSpan()
   public static isNull(): any {
     return Raw((alias: string) => {

package/Server/Utils/AnalyticsDatabase/QuerySettingsHelper.ts

@@ -25,6 +25,46 @@ export const DEFAULT_MAX_BYTES_BEFORE_EXTERNAL_GROUP_BY_IN_BYTES: number = 16106
 // 1.5 GiB.
 export const DEFAULT_MAX_BYTES_BEFORE_EXTERNAL_SORT_IN_BYTES: number = 1610612736;
 
+/*
+ * Scan-side memory bound for wide-window aggregations.
+ *
+ * A GROUP BY over a log window has to visit every matching row, so unlike a
+ * paginated list it cannot be made to read less. What it CAN be stopped from
+ * doing is holding a huge amount of that data in flight at once: peak memory
+ * is roughly (threads x block rows x bytes per row), and a row carrying the
+ * fat `attributes` Map(String, String) is expensive. Reading the default
+ * 65536 rows per block per thread is what pushes a filtered facet or a
+ * projection-fallback histogram past max_memory_usage and into Code 241.
+ *
+ * These are execution-strategy settings only — ClickHouse returns the same
+ * rows either way (asserted in QuerySettingsHelper.test.ts and verified
+ * against a real server).
+ *
+ * Measured on ClickHouse 26.7, 3M rows shaped like LogItemV3, one facet
+ * query filtered on an attribute:
+ *
+ *   default                                695 MiB peak
+ *   max_block_size alone                    88 MiB peak (and faster)
+ *   + preferred_block_size_bytes, threads   40 MiB peak
+ *
+ * NOTE: this bounds SCAN memory, not aggregation state. A facet on a
+ * genuinely high-cardinality attribute builds a large hash table regardless;
+ * that case is covered by max_bytes_before_external_group_by spilling to
+ * disk, which is already applied to every read here.
+ */
+export const AGGREGATION_SCAN_MAX_BLOCK_SIZE: number = 8192;
+
+// 1 MiB — caps a block by bytes when rows are unusually wide.
+export const AGGREGATION_SCAN_PREFERRED_BLOCK_SIZE_IN_BYTES: number = 1048576;
+
+/*
+ * The Logs sidebar fans out one aggregation per facet key concurrently, so
+ * per-query thread caps also bound how much of the server a single page load
+ * can claim. Latency is barely affected — these queries are already bounded
+ * by max_execution_time with 'break'.
+ */
+export const AGGREGATION_SCAN_MAX_THREADS: number = 4;
+
 export interface QuerySettingsOptions {
   /**
    * Wall-clock cap in seconds (max_execution_time). Omitted from the
@@ -40,6 +80,13 @@ export interface QuerySettingsOptions {
   maxMemoryUsageInBytes?: number | undefined;
   maxBytesBeforeExternalGroupByInBytes?: number | undefined;
   maxBytesBeforeExternalSortInBytes?: number | undefined;
+  /**
+   * Bounds how much data a scan holds in flight, for aggregations that must
+   * visit every row in a wide window. Emits max_block_size,
+   * preferred_block_size_bytes and max_threads. Execution strategy only —
+   * the result set is unchanged. See AGGREGATION_SCAN_MAX_BLOCK_SIZE.
+   */
+  boundScanMemory?: boolean | undefined;
   /**
    * Site-specific passthrough settings (e.g. optimize_use_projections,
    * optimize_aggregation_in_order, max_threads). Keys and values are
@@ -77,6 +124,18 @@ export function getQuerySettings(options?: QuerySettingsOptions): string {
     }`,
   );
 
+  /*
+   * Emitted before additionalSettings so a call site can still override any
+   * one of these explicitly if it has a reason to.
+   */
+  if (options?.boundScanMemory) {
+    parts.push(`max_block_size = ${AGGREGATION_SCAN_MAX_BLOCK_SIZE}`);
+    parts.push(
+      `preferred_block_size_bytes = ${AGGREGATION_SCAN_PREFERRED_BLOCK_SIZE_IN_BYTES}`,
+    );
+    parts.push(`max_threads = ${AGGREGATION_SCAN_MAX_THREADS}`);
+  }
+
   if (options?.additionalSettings) {
     for (const [key, value] of Object.entries(options.additionalSettings)) {
       parts.push(